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...
Rust Never Sleeps
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
Rust Never Sleeps
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.
Senast redigerad av Erik-NA den 2012-12-02 klockan 20:28.
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.
Senast redigerad av Erik-NA den 2012-12-02 klockan 21:51.
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.
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
Behörigheter för att posta
Svara med citat
