[solved] Probleme mit Spulen in SD

Ich kann das Problem bei mir bestätigen. Es tritt auf mit SD und HD-Aufnahmen, ebenso mit Aufnahmen vom pvrinput-Plugin.

Leider läßt sich es nicht mit einem dist-upgrade lösen, so daß es nach wie vor besteht.

Ich verwende den aktuellen Stand von:

deb http://ppa.launchpad.net/yavdr/stable-vdr/ubuntu lucid main
deb http://ppa.launchpad.net/yavdr/stable-xbmc/ubuntu lucid main
deb http://ppa.launchpad.net/yavdr/stable-yavdr/ubuntu lucid main

Ausgabe ist per xineliboutput

Da die Installation sehr neu ist, kann ich nicht sagen, seit wann das Problem besteht.

Hallo,

ist mir bei meinem VDR auch gerade aufgefallen. Vorspulen geht ohne Probleme. Beim Zurückspulen erhalte ich folgende Meldungen im Log:

Start zurückspulen:

Mar 31 10:26:40 VDRFFM vdr: [12951] [xine..put] Detected video size 720x576
Mar 31 10:26:40 VDRFFM vdr-sxfe[1734]: [1745] [input_vdr] wait_stream_sync: discard_index 27567112470 != curpos 27567095550 ! (diff 16920)
Mar 31 10:26:40 VDRFFM vdr-sxfe[1734]: [1745] [demux_vdr] PMT changed, resetting demuxer

Ende zurückspulen:

Mar 31 10:26:41 VDRFFM vdr: [12951] [xine..put] Detected video size 720x576
Mar 31 10:26:41 VDRFFM vdr-sxfe[1734]: [1745] [input_vdr] wait_stream_sync: discard_index 27570498914 != curpos 27570219170 ! (diff 279744)
Mar 31 10:26:41 VDRFFM vdr-sxfe[1734]: [1745] [demux_vdr] PMT changed, resetting demuxer

Spule ich in der Aufnahme nach vorne gibt es keine Meldungen im Logfile.

Ich habe die aktuellsten Updates aus dem stable Repo auf dem VDR.

Grüße,
Olaf

kann ich zu 100% bestätigen.

Apr  6 21:43:29 ubuntuvdr1 vdr-sxfe[2762]: [2786] [input_vdr] wait_stream_sync: discard_index 873909596 != curpos 873666888 ! (diff 242708)
Apr  6 21:43:29 ubuntuvdr1 vdr-sxfe[2762]: [2786] [demux_vdr] PMT changed, resetting demuxer
Apr  6 21:43:29 ubuntuvdr1 vdr: [2628] [xine..put] cXinelibServer::GetSTC timeout
Apr  6 21:43:29 ubuntuvdr1 vdr: [2628] [xine..put] cXinelibServer::GetSTC timeout
Apr  6 21:43:29 ubuntuvdr1 vdr: [3875] [xine..put] cXinelibServer::GetSTC timeout
Apr  6 21:43:29 ubuntuvdr1 vdr: [3875] [xine..put] cXinelibServer::GetSTC timeout
Apr  6 21:43:29 ubuntuvdr1 vdr: [2628] [xine..put] cXinelibServer::GetSTC timeout
Apr  6 21:43:29 ubuntuvdr1 vdr: [3875] [xine..put] cXinelibServer::GetSTC timeout
Apr  6 21:43:29 ubuntuvdr1 vdr: [2628] [xine..put] cXinelibServer::GetSTC timeout
Apr  6 21:43:29 ubuntuvdr1 vdr: last message repeated 3 times
Apr  6 21:43:29 ubuntuvdr1 vdr: [2628] [xine..put] OSD bandwidth: 718238 bytes/s (5611 kbit/s)
Apr  6 21:43:29 ubuntuvdr1 vdr: [2628] [xine..put] cXinelibServer::GetSTC timeout
Apr  6 21:43:29 ubuntuvdr1 vdr: last message repeated 6 times
Apr  6 21:43:29 ubuntuvdr1 vdr: [3875] [xine..put] cXinelibServer::GetSTC timeout
Apr  6 21:43:29 ubuntuvdr1 vdr: [2628] [xine..put] cXinelibServer::GetSTC timeout
Apr  6 21:43:29 ubuntuvdr1 vdr: [2628] [xine..put] cXinelibServer::GetSTC timeout
Apr  6 21:43:29 ubuntuvdr1 vdr: [3875] [xine..put] cXinelibServer::GetSTC timeout
Apr  6 21:43:29 ubuntuvdr1 vdr: [3875] [xine..put] cXinelibServer::GetSTC timeout
Apr  6 21:43:29 ubuntuvdr1 vdr: [2628] [xine..put] cXinelibServer::GetSTC timeout
Apr  6 21:43:29 ubuntuvdr1 vdr: [3875] [xine..put] cXinelibServer::GetSTC timeout
Apr  6 21:43:29 ubuntuvdr1 vdr: [2628] [xine..put] cXinelibServer::GetSTC timeout
Apr  6 21:43:29 ubuntuvdr1 vdr: last message repeated 2 times

vielleicht mag da einer vom yavdr-Team was zu sagen?

das gute:
in unstable mit vdr-1.7.17 und aktueller libxine
sollte das nicht mehr sein.
zumindest hier geht das alles ohne probleme egal ob hd oder sd !

ABER
wann das ganze nach stable-vdr kommt kann ich nicht sagen

meiner meinung nach ist das unstable ppa im moment mehr stable als das stable

hatte eben dies mit meiner 0.3 - version nach einem Absturz auch, begleitet von dramatischen Bildrucklern und Artefakten an dunklen Bildstellen. Habs mit dem Rückspielen eines Backups "gelöst".

Bei mir was ähnliches, allerdings entweder beim Starten einer Aufnahme, oder wenn ich nach einer Zeit den TV dazuschalte (VDR läuft schon eine Weile).

Apr 28 12:02:42 vdr vdr: [1409] [extrecmenu] starting replay of recording
Apr 28 12:02:42 vdr vdr: [1409] loading /srv/vdr/video.00/Serie/Navy_CIS/02x03_Auge_um_Auge/2011-04-28.05.35.41-0.rec//marks
Apr 28 12:02:42 vdr vdr: [1409] replay /srv/vdr/video.00/Serie/Navy_CIS/02x03_Auge_um_Auge/2011-04-28.05.35.41-0.rec
Apr 28 12:02:42 vdr vdr: [1409] playing '/srv/vdr/video.00/Serie/Navy_CIS/02x03_Auge_um_Auge/2011-04-28.05.35.41-0.rec/00001.ts'
Apr 28 12:02:42 vdr vdr: [1409] loading /srv/vdr/video.00/Serie/Navy_CIS/02x03_Auge_um_Auge/2011-04-28.05.35.41-0.rec//marks
Apr 28 12:02:42 vdr vdr: [3780] Text2Skin: menu display update thread ended (pid=1409, tid=3780)
Apr 28 12:02:42 vdr vdr: [3847] dvbplayer thread started (pid=1409, tid=3847)
Apr 28 12:02:42 vdr vdr: [3847] resuming replay at index 0 (0:00:00.01)
Apr 28 12:02:42 vdr vdr: [3848] non blocking file reader thread started (pid=1409, tid=3848)
Apr 28 12:02:42 vdr vdr: [3847] [xine..put] Detected video size 720x576
Apr 28 12:02:42 vdr vdr: [3656] TS buffer on device 2 thread ended (pid=1409, tid=3656)
Apr 28 12:02:42 vdr vdr: [3655] buffer stats: 94000 (4%) used
Apr 28 12:02:42 vdr vdr: [3655] receiver on device 2 thread ended (pid=1409, tid=3655)
Apr 28 12:02:42 vdr vdr-sxfe[3558]: [3569] [demux_vdr] PMT changed, resetting demuxer
Apr 28 12:02:43 vdr vdr: [1588] [xine..put] cXinelibServer::GetSTC timeout
Apr 28 12:02:48 vdr vdr: last message repeated 4 times
Apr 28 12:02:48 vdr kernel: [12137.246926] saa7146 (0) vpeirq: used 1 times >80% of buffer (172396 bytes now)
Apr 28 12:02:48 vdr vdr: [1588] [xine..put] cXinelibServer::GetSTC timeout
Apr 28 12:03:05 vdr vdr: last message repeated 17 times
Apr 28 12:03:05 vdr vdr: [1409] [xine..put] cXinelibServer::GetSTC timeout
Apr 28 12:03:05 vdr vdr: [3848] non blocking file reader thread ended (pid=1409, tid=3848)
Apr 28 12:03:05 vdr vdr: [3847] dvbplayer thread ended (pid=1409, tid=3847)
Apr 28 12:03:05 vdr vdr: [1409] switching to channel 9
Apr 28 12:03:05 vdr vdr: [3849] receiver on device 2 thread started (pid=1409, tid=3849)
Apr 28 12:03:05 vdr vdr: [3850] TS buffer on device 2 thread started (pid=1409, tid=3850)
Apr 28 12:03:05 vdr vdr: [3851] Text2Skin: menu display update thread started (pid=1409, tid=3851)
Apr 28 12:03:06 vdr vdr: [3849] [xine..put] cXinelibServer::Play Buffer overflow (TCP/PIPE)
Apr 28 12:03:06 vdr vdr: last message repeated 13 times
Apr 28 12:03:06 vdr vdr: [3849] [xine..put] Detected video size 720x576
Apr 28 12:03:06 vdr vdr: [3849] [xine..put] cXinelibServer::Play Buffer overflow (TCP/PIPE)
Apr 28 12:03:09 vdr vdr: last message repeated 986 times
Apr 28 12:03:09 vdr vdr: [3849] [xine..put] cXinelibServer: Too many TCP buffer overflows, dropping client
Apr 28 12:03:09 vdr vdr: [3849] [xine..put] cXinelibServer::Play Write/Queue error (TCP/PIPE)
Apr 28 12:03:09 vdr vdr: [3849] [xine..put] Closing connection 0
Apr 28 12:03:43 vdr vdr: [3851] Text2Skin: menu display update thread ended (pid=1409, tid=3851)

Zitat von hotzenplotz5

das gute:
in unstable mit vdr-1.7.17 und aktueller libxine
sollte das nicht mehr sein.
zumindest hier geht das alles ohne probleme egal ob hd oder sd !

ABER
wann das ganze nach stable-vdr kommt kann ich nicht sagen

meiner meinung nach ist das unstable ppa im moment mehr stable als das stable

Alles anzeigen

Man sollte aber nur auf unstable ppa umstellen wenn man xine benutzt. Xineliboutput funktioniert nicht mehr und ich musste deshalb erst einmal auf xine umstellen. Meine Versuche xineliboutput wieder mit lucid an den Start zu bekommen, sind gescheitert. Vielleicht hat jemand ja einen Tipp .

Gruß

Obelix

Na Ja... ist das der offizielle Tipp? Gibt's da eine Anleitung für's Umstellen? Und im Fehlerfall wieder zurück?

Zitat von iso

Na Ja... ist das der offizielle Tipp? Gibt's da eine Anleitung für's Umstellen? Und im Fehlerfall wieder zurück?

Nun, du musst das stable ppa wieder aktivieren und das unstable deaktivieren. Dann ein apt-get update und die aus dem unstable installierten Pakete mittels apt-get install --reinstall [paketname] erneut installieren. Nicht mal eben gemacht aber nicht umsonst wird davor gewarnt.

Ich werde mir die Arbeit wohl auch machen müssen (außer jemand hat einen Tipp, wie man xineliboutput im unstable ppa wieder an den Start bringt). Mit vdr-xine-0.9.4 bekomme ich auch Ton- und Bildruckler wie bei vdr-xine-0.9.3.

Gruß

Obelix

Bild oder Tonruckler bei Live-TV? Ich kenne das von 1.6 bei Live-TV, dass der Ton kurz weg ist. Ist mir aber gleich, hab immer direkt auf die Pause-Taste gehauen, 10sek warten und gut ist. Aber dass das frontend komplett einfriert geht gar nicht. Xine oder XineLibOutput ist mir eigentlich auch gleich, hauptsache das Bild läuft durch. Kümmert den Anwender nicht, was da im Hintergrund läuft.

Ich mach mir mal Gedanken, wie ich ein vernünftiges Backup hinbekomme, das sozusagen auch den "SystemState" berücksichtigt. Nicht nur config's, sondern im Prinzip das ganze System (trotz LVM...).

Hilfreich wäre offene Probleme nicht in Threads zu diskutieren die auf gelöst stehen. Zumindest ich ignoriere die komplett wenn ich knapp an Zeit bin. Denke geht es anderen ähnlich.

Zitat von iso

Bild oder Tonruckler bei Live-TV? Ich kenne das von 1.6 bei Live-TV, dass der Ton kurz weg ist. Ist mir aber gleich, hab immer direkt auf die Pause-Taste gehauen, 10sek warten und gut ist. Aber dass das frontend komplett einfriert geht gar nicht. Xine oder XineLibOutput ist mir eigentlich auch gleich, hauptsache das Bild läuft durch. Kümmert den Anwender nicht, was da im Hintergrund läuft.

Ich mach mir mal Gedanken, wie ich ein vernünftiges Backup hinbekomme, das sozusagen auch den "SystemState" berücksichtigt. Nicht nur config's, sondern im Prinzip das ganze System (trotz LVM...).

Bei vdr-xine bekomme ich nach ca. 30 Minuten (kann auch mal länger dauern) Tonaussetzer und Bildruckler. Beides passiert zusammen. Bei xineliboutput habe ich auch des Öfteren Hänger, weshalb ich auf das unstable ppa gegangen bin.

Zitat von steffen_b

Hilfreich wäre offene Probleme nicht in Threads zu diskutieren die auf gelöst stehen. Zumindest ich ignoriere die komplett wenn ich knapp an Zeit bin. Denke geht es anderen ähnlich.

Danke für den Hinweis. Habe ich in meiner Verzweiflung glatt übersehen. Ich klammere mich aktuell an jeden Strohhalm um dieses Problem zu lösen.

Gruß

Obelix