Utskriftsvy
Håller på att utforska MythTv. Har inte kommit långt med tanke på hur många inställningar det finns.
I vilket fall som helst. När jag kollar på LiveTV med Mythfrontend hackar bilden till då och då. Bilden tappar liksom sync under delar av en sekund. Jag har en känsla av att det kan bero på sasc-ng som får någon buffer full? Finns det någon parameter till sasc-ng där man kan öka bufferten (eller något sådant)?
Svarar mig själv. Lägger man till parameter -b så kan man ställa bufferten. Jag provade med -b 16M och då minskade delar av problemet.
Man kan max sätta den till 20M.
Fortfarande är det problem med lagg då och då. Provade att trycka på A för att minska uppspelningshastigheten och vid 0.85 verkar problemet förvinna. Dock verkar parametern nollställas varje gång man byter kanal etc?
Japp kör också med --buffer 16M som parameter
man kan ändra i koden till sasc för att få mer buffert...
Att det hackar till ibland och vill buffra kan bero på dålig signal med...
Kan också vara inställningar till ljudet
Kör iaf med dessa parametarar "--daemon --cam-budget --sid-allpid --sid-nocache --buffer 16M"
Testa att starta myththv i ett fönster: myhthfrontend --geometry 800x600 då kan du läsa av i realtid när det hackar till...
och du använder HW-decoders för att fixa skala mm
Jag laddade ned en inspelning via ssh och provade att kika på den i VLC och där laggade det också. Därmed tolkar jag detta som ett backendproblem. I frontend kör jag med HW-decoding mha VDPAU
Skillnaden mot dig Plow är att jag inte har med "--deamon" i konfen, jag startar sasc-ng med ett skript.
Skall även kolla upp detta med signalkvalité. I mythfrontend finns det en funktion för att visa teknisk info om avkodning, signalkvalité etc. Slog på den för någon dag sedan, missade dock att notera hur jag gjorde det...
Noterar även att problemet med "laggning" sker på HD-kanaler. På SD-kanaler har jag inte noterat något "lagg".
Jag startar också via ett script..
Kan du öka ringbuffer ? snabbare disk i backend
Ringbuffer är omkonfat till 18400, dubblerade det igår. Skall kanske öka ännu mer? Använder två Asrock frontends och om båda kollar på HD så är det kanske bra att ha den högt satt?
Har annars en SSD-disk för operativet och en 3TB RAID-5 array med Haupaugge RAID-kort i backend.
Flyttade "default storage group" till raid5-arrayen häromdagen. Skall nog lägga tillbaka RealTv-mappen till SSD:n för ökad hastiget.
Tack för alla tips, det uppskattas enormt!!
Kan ju vara oscam som strular också...
Har nu dubblerat ringbuffer yterliggare till 36800, utan positivt resultat. (Inget swap)
Kollade lite i mappen livetv och där fanns det nu 80GB "temp-inspelat" data, så den går inte att flytta till SSD utan vidare då det är för mycket data. Går det att begränsa hur stor liveTv-mappen får vara?
Gällande oscam så får jag lite fel i loggen då och då, den hittar inte alla efterfrågade program. Svårt att se om det är det som är problemet.
kollat lite i loggen på mythbackend och där står följande "I ProcessRequest ringbuffer.cpp:1098 (WaitForAvail) RingBuf(/mnt/storage/mythtv/livetv/5204_20121202153841.mpg): Waited 0.2 seconds for data #012#011#011#011to become available"
Skall nog försöka flytta tillbaka default storage.
Du kan radera livetv inspelningarna från mythweb.
Kan ju vara så jävligt att du har fel på din ssd. Boota med någon bootcd och gör en surface scan...
Grejjen är att liveTv sparade på Raid5-arrayen. Provade att flytta över dem till SSD:n och då försvann felet inledningsvis. Dock fick jag andra fel som förmodligen skapade lagg.
mythlogserver: mythbackend[2612]: I ProcessRequest ringbuffer.cpp:1098 (WaitForAvail) RingBuf(/var/lib/mythtv/livetv/5204_20121202173145.mpg): Waited 0.2 seconds for data #012#011#011#011to become available
Har en extra SSD som jag nu provat som storage group och nu verkar problemet vara minimerat, även om felet i loggen kvarstår och att det laggar lite ibland. Problemet uppstår bara på HD-kanaler då bithastigheten är som störst. Undrar hur jag kan undvika det? Det bör inte vara själva disken, det måste vara något annat IO-problem, frågan är bara vad och vad jag kan göra?
CPU är inte speciellt belastad. Sasc-ng drar ca 15% CPU för att avkoda två HD-kanaler samtidigt.
Kan det vara filsystemet ? Jag kör xfs...
kör iotop när du spelar in för att kolla io
Atop är också bra
Läser man feltexten så kan man tro att det beror på att HD-ringbuffer size är för stor? "Waited 0.5 seconds for data become available..."
Skall prova att ställa ned den till 4700.
Dessutom har man gjort om implementationen efter MythTv 0.19. Det är inte längre någon ringbuffer, utan liveTv hanteras som en inspelning. Därmed kan man fundera över vad parametern har för ny betydelse? Är det så att data buffras i RAM innan det skickas till hårddisken?
iotop visar att mythbackend skriver med ca 1500 K/s per adapter (en instans per adapter). Läsaktiviteten är i princip noll.
Läser här: http://code.mythtv.org/trac/ticket/10428
The commit has been committed to master/pre0.26, and it will therefore at least be part of the soon-to-be-released MythTV 0.26. The commit might be backported to 0.25-fixes, if so, you'll see the 0.25-fixes commit here and you should be able to pick it up from the Mythbuntu autobuilds.
Frågan är om detta är en bugg i loggen, eller om det är en bugg i applikationen? Och om den påverkar min laggning? När det laggar hos mig skrivs dock felet i loggen.
Fanns en relaterad bugg som också förmodligen påverkar detta: http://code.mythtv.org/trac/changese...06f6b8a/mythtv
Hur som helst. Gjorde en apt-get update och uppdaterade myth både på front och backend. Det blev kanske bättre, men inte problemfritt. Problemen i loggen kvarstår, liksom laggning vid uppspelning.
By the way. Såg att fenomenet kallas för "stuttering", inte laggning som jag skrivit.
Bytte till XFS på SSD:n. Nu är problemet minimerat, men ändå finns det lite stuttering kvar på HD-kanalerna. Irriterande att det inte är problemfritt. :mad:
Skall undersöka signalstyrkan och se om det kan vara relaterat till kanske för låg insignal från LNB?.
Skall också undersöka vad HD-ringbuffer size har för betydelse i dagens MythTv då dokumentationen inte är uppdaterad.
Slutligen är det kanske så att detta är ett problem som inte är helt löst i den senaste utgåvan av MythTv 0.26 som Mythbuntu har i sitt PPA? Finns en hel del information att läsa om detta problem.
har du kollat klippen i nån annan dator / media spelare så felen inte är relaterade med 50p/60p o du får mecka lite med xorg.conf o kolla lite i vdpau sektionen i mythwikin om tips
du kan ju se i mythtv om det är bitfel via meny/uppspelning/UppSpelningsinformation
/Mixo
Jorå, jag har laddat ned livetv-inspelning och kollat i VLC på Windows 7 och där uppstår fenomenet också.
Stuttering sker samtidigt som jag får fel i mythbackend log:
mythlogserver: mythbackend[2612]: I ProcessRequest ringbuffer.cpp:1098 (WaitForAvail) RingBuf(/var/lib/mythtv/livetv/5204_20121202173145.mpg): Waited 0.2 seconds for data #012#011#011#011to become available
Tack för tipset gällande uppspelningsinformation. Men den indikerar inte något fel.
Jag tycker detta luktar som ett fel i backend någonstans. Särskilt när man läser att andra har problem med MythTv 0.26 om man söker på "mythbuntu stuttering livetv" i google. Det som är oroande är att inläggen är lite gamla.
Efter ett påpekande är detta nog ett problem som snarare är relaterat till inspelning än till uppspelning. Det kan stämma eftersom felmeddelandet säger att ringbuffern väntar på data.
Skall därför fokusera felsökningen på att kolla om insignalen till MythTV är störd. Det kan jag göra med mplayer. Även om det tar emot (kallt och snö på taket) så måste jag även kontrollera om parabolen är rätt inställd mot Thor, dvs maximera insignalen från LNB.
Skall även kolla om det finns nya drivrutiner till DVB-S-kortet. Det kan också bero på att DVB-S-kortet sitter i fel slot i datorn vilket påverkar interrupts då datorn är fullsmetad med ett antal nätverkskort och ett raidkort. Slutligen kan det bero på sasc-ng.
Uppslag finns det, det gäller bara att beta av dem....
En sak som jag funderar på är att efter jag ändrade att default storage-group skulle lagras på SSD:n istället för på Raid-arrayen minskade fenomenet. Det pekar på att det kanske är problem med interrrupts, dvs jag måste disponera om placeringen av korten så DVB-S-kortet får ett annat interrupt?
Som sagt, jag har en del att göra...
cat /proc/interrupts
Ja då det är bara i HD kanalerna som felet uppkommer i så låter det som signal fel, du kan ju prova o ladda hem nåt hd klipp o använda Video pluginet för o kolla om det funkar med den. det finns även möjlighet idag att koppla ett tv kort till ett videoklipp bara för o prova oxå.
Igårkväll flyttade jag runt korten så att DVB-kortet får eget interrrupt. Men tyvärr är "stutteringen" kvar. Har också sett att det är "stuttering" på SD-kanaler, dock lite.
Jag vill nog tro att detta är ett inspelningsproblem. Jag har genom diverse åtgärder minskat "stutteringen", men den är inte borta helt, det är tillräckligt mycket kvar för att vara irriterande.
Det som är kvar är att kontrollera signalkvalitén från LNB, men just nu är det snöoväder ute så det får vänta tills vädret bättrar sig.
Om du spelar upp utan att använda mythtv då? Dvs med szap och t.ex mplayer. Då kan du iaf utesluta att det är mythbackend om det rycker då med
Jag provade mplayer och szap ikväll och kunde inte se någon stuttering. Men jag tyckte inte bilden uppdaterades tillräckligt ofta (och så hade jag inget ljud), så jag kan dessvärre inte utesluta något ännu.
The hunt is still on...
Testa tvheadend med. Utan sasc...
Har testat tvheadend men får tyvärr inte in några HD-kanaler. Har även bytt moderkort och även CPU, och därmed också ominstallerat backend.
Har nästan betat av min lista. Det som är kvar är att justera själva parabolen för att maximera insignalen från LNB. Har nu en insignal på cirka 74% vilket är dåligt och jag hoppas att problemet beror därav. Det har varit för kallt i helgen (-18 som kallast) för att stå på det snöiga taket och fippla med sköra koaxkablar. Har skaffat ett mätinstrument på Clas Ohlson, http://www.clasohlson.com/se/Satelli...re/Pr384554000 för att justera in parabolen.
Igårkväll stod jag på taket och försökte maximera insignalen från LNB. Kunde inte maximera mer än vad den var.
Detta får mig att fundera lite då det inte var några problem med boxarna från CD. Visst, DVB-kortet har kanske en sämre mottagardel, men det får ändå mig att bli lite misstänksam. Är det DVB-drivern eller sasc-ng?
Min startsträng till sasc-ng ser ut så här: "-j 0:4 -j 1:5 -j 2:6 -j 3:7 --cam-budget --sid-allpid --sid-nocache -d 0xf0a -b 16M --cam-dir /etc/camfiles/"
Plow startar sin sasc som deamon, det gör inte jag. Kan det påverka? Måste prova lägga till --deamon.
Är det någon som vet var parametern -d gör? Har Googlat med inte funnit något svar.
Jag ligger också kring 72-74 med mitt rutta USB-kort
Tv-korten har mycket svagare förstärkning än vanliga mottagare.
Spelar ingen roll om du kör sasc i terminalen eller som deamon...
Med mitt tbs 6981 så ligger jag på 74% vilket verkar vara max och med mitt Tevii 470s så ligger jag på 84% och jag startar sasc-ng med en rad i rc.local
su - mythtv -c "export LD_LIBRARY_PATH=/home/mythtv/.sasc-ng/lib && cd .sasc-ng && screen -dmS scam ./sasc-ng --cam-budget -j0:3 -j1:4 -j2:5 "
/Mixo
Tack för info Mixo.
Mitt TBS 6984 säger just 74% och det är kanske max för TBS-kort?
Försöker analysera det startupskript (http://www.comhit.net/showwiki.php?t...igital#SASC-NG) med ditt.
Du anger LD_LIBRARY_PATH. Jag kopierar lib-filerna till /usr/lib/ under installation av sasc-ng och därmed behöver jag inte ange LD_LIBRARY_PATH?
Jag även kör med fler växlar till sasc-ng: --sid-allpid --sid-nocache -d 0xf0a --buffer 16M
Får prova mig fram och se om det hjälper att plocka bort något.
Om det fungerar att koda av har sasc alla libs den behöver...
Aktiverade loggning i sasc-ng för att kontrollera om det är något där som strular med min stuttering på HD-kanaler. Men sasc-loggen larmar inte om något onormalt när mythbackend.log larmar om "I ProcessRequest ringbuffer.cpp:1098 (WaitForAvail) RingBuf(/mnt/mythtv/livetv/5104_20121212072322.mpg): Waited 0.2 seconds for data #012#011#011#011to become available..." i batcher med olika slumpmässiga intervall
Nu kommer man till den delen av felsökningsprocessen då man börjar greppa efter halmstrån och prova saker som man tidigare inte har tänkt på, nedprioriterat, minst troligt eller uteslutit av någon anledning. Som exempel skall jag förlänga mittenledaren (kontaktera om kabeln) i koaxen eftersom jag såg att kontakterna på DVB-kortet har en lång gänga.
Pröva att dra ner loggningen på sasc. I varjefall den versionen på github synkar loggarna lite väl ambitiöst mot disk, så det tar 50-100 ms att logga en rad. Om man har mycket loggning påslagen så är det säkert möjligt att det påverkar I/O i stort att systemet fokuserar på att tt skriva några tecken till en loggfil, istället för att plöja mpeg filer...
Loggning finns inte med sedan någon vecka, såg att den tar en hel del diskutrymme över tiden. Slår bara på den vid behov.
Skall gräva i detta med kablaget. Dock är det så att MythTvFrontend inte verkar visa mer än max 74% hur jag än gör. Samma fenomen har tydligen Mixo för sitt TBS-kort.
Skall även prova att söka om kanalerna en gång till. Påminner mig nämligen om att när jag sökte efter kanaler senast noterade jag att den hittade dubbla HD-kanaler på SID:ar (heter det så?) bredvid varandra, vilket jag tycker är lite mysko.
Så sasc-ng på github? https://github.com/bas-t/Sasc-ng?
Jag är lite sugen att testa någon typ av förstärkning till parran...
Du har ingen USB-lagringsenhet ansluten ? Det kan göra att du får kass I/O prestanda...
Nopz. Det som går via USB är Phoenix-läsaren.
Igårkväll provade jag med att ladda ned sasc-ng från github, https://github.com/bas-t/Sasc-ng. Det är rev 570 med vdr-sasc-ng-2.6.38.patchen. Ingen ändring dock, samma fel. :(
Det som jag funderar på är om jag skall backa min TBS-driver till en äldre version och se om felet kvarstår?
En annan långsökt fundering är att jag kör sasc-ng som root, kan det ha någon betydelse när mythtv körs som användaren mythtv? Mindre troligt, men nu är mina halmstrån väldigt korta...
Var också inne på att mina frontends hade problem då SVT1 och SVT2 kör 1280x720@50 medan BBC HD kör 1920x1088@25. Problemet tycks nämligen förvärras när det är stora vita ytor i bilden så som moln etc Men det är bara ett tyckande, kan inte bekräfta det.
Om jag laddar ned en liveTV-inspelning via mythwebb och ser den lokalt på en annan dator med exempelvis VLC finns störningarna där. Det är mao minst ett inspelningsproblem.
Jag kan inte med säkerhet koppla problemet till felmeddelande i loggen "ProcessRequest ringbuffer.cpp:1098 (WaitForAvail) RingBuf(/mnt/mythtv/livetv/5104_20121215071200.mpg): Waited 0.2 seconds for data #012#011#011#011to become available... 360448 < 458752" men det känns som så. Dock uppträder stuttering ibland utan felmeddelande i mythbackendlog, vilket motsäger min känsla.
Jag börjar bli lite nyfiken på att ladda ned sourcen till MythTv och leta rätt på felmeddelande i koden och se vad det kan bero på. Är det relaterat till att det saknas information från drivern (sasc-ng) eller är det relaterat till skickandet av information till frontend?
Har nu provat att öka "ringbuffer size" till 75200 med motivet att det är HD-kanaler som råkar ut för stuttering och HD-kanaler innebär stor bandbredd, vilket kanske gör att buffern hinner bli full innan den töms? Ringbuffer size är angiven i kB vilket innebär att buffern är nu ca 77MB stor.
Som sagt, mina halmstrån börjar bli korta...