[ANNOUNCE] VDR developer version 1.7.5

Zitat

Original von kls

(Es lebe 7-Bit ASCII - wer auch immer dieses UTF-8 Zeugs erfunden hat, möge furchtbare Qualen erleiden...

Eben, wer braucht schon die komischen Zeichen die sollen alle mal ne vernünftige schrift lernen
Zu GSM zeiten hat doch 7 bit vollkommen gereicht

SCNR

fab

Hi,
ich bin noch nicht so lange dabei, daher verzeiht mir wenn ich was frage, was möglicherweise bekannt ist:
- Kann ich aufgrund der TS Features der 1.7.5 problemlos meine alten TS Stream Recordings von Neutrino (DBox2) damit wiedergeben?
- Der Support für eine Skystar HD2 würde mich auch interessieren. Warum wird nur der v4l unterstützt und nicht mehr die anderen Treiber? ODer kann sich das noch ändern?

Hi,

irgendwie ist der VDR nach einem Update von 1.7.4 auf 1.7.5 nicht mehr benutzbar, sobald Aufnahmen laufen. Ich verwende zwei DVB-C Karten (TT-C2300 u. Cinergy C1200). Aktuell laufen 2 Aufnahmen. Sobald ich zwischen Kanälen umschalte, friert das Bild irgendwann ein. Nach ca. 2 Minuten werden alle über die Fernbedienung abgesetztetn Befehle dann doch ausgeführt. Im Log sehe ich folgendes:

Apr 16 23:10:00 linux-qgjx vdr: [23224] (tools.c:342) creating directory /var/spool/video/Navy_CIS/Navy_CIS/Don_16.04.2009-23:15/2009-04-16.23.10.4-0.rec
Apr 16 23:10:00 linux-qgjx vdr: [23224] (recording.c:1636) recording to '/var/spool/video/Navy_CIS/Navy_CIS/Don_16.04.2009-23:15/2009-04-16.23.10.4-0.rec/00001.ts'
Apr 16 23:10:00 linux-qgjx vdr: [24777] (thread.c:302) recording thread started (pid=23224, tid=24777)
Apr 16 23:10:00 linux-qgjx vdr: [24778] (thread.c:302) receiver on device 2 thread started (pid=23224, tid=24778)
Apr 16 23:10:00 linux-qgjx vdr: [24779] (thread.c:302) TS buffer on device 2 thread started (pid=23224, tid=24779)
Apr 16 23:10:02 linux-qgjx vdr: [23230] (epg.c:164) channel 3 (RTL Television) event Don 16.04.2009 23:10-00:00 'Prison Break' status 4
Apr 16 23:10:03 linux-qgjx vdr: [23230] (epg.c:164) channel 6 (RTL 2) event Don 16.04.2009 23:10-00:10 'EXKLUSIV - DIE REPORTAGE' status 4
Apr 16 23:10:26 linux-qgjx vdr: [23224] (device.c:588) switching to channel 4
Apr 16 23:11:09 linux-qgjx vdr: [23224] (device.c:588) switching to channel 5
Apr 16 23:11:16 linux-qgjx vdr: [23224] (device.c:588) switching to channel 6
Apr 16 23:11:21 linux-qgjx vdr: [23224] (device.c:588) switching to channel 7
Apr 16 23:11:24 linux-qgjx vdr: [23224] (device.c:588) switching to channel 6
Apr 16 23:11:24 linux-qgjx vdr: [23224] (device.c:588) switching to channel 5
Apr 16 23:11:25 linux-qgjx vdr: [23224] (device.c:588) switching to channel 4
Apr 16 23:11:27 linux-qgjx vdr: [23224] (device.c:588) switching to channel 3
Apr 16 23:11:34 linux-qgjx vdr: [24782] (thread.c:302) femon receiver thread started (pid=23224, tid=24782)
Apr 16 23:11:34 linux-qgjx vdr: [24783] (thread.c:302) femon osd thread started (pid=23224, tid=24783)
Apr 16 23:11:40 linux-qgjx vdr: [23224] (device.c:588) switching to channel 4
Apr 16 23:11:40 linux-qgjx vdr: [24782] (thread.c:310) femon receiver thread ended (pid=23224, tid=24782)
Apr 16 23:11:40 linux-qgjx vdr: [24784] (thread.c:302) femon receiver thread started (pid=23224, tid=24784)
Apr 16 23:11:45 linux-qgjx vdr: [23224] (device.c:588) switching to channel 5
Apr 16 23:11:45 linux-qgjx vdr: [24784] (thread.c:310) femon receiver thread ended (pid=23224, tid=24784)
Apr 16 23:11:45 linux-qgjx vdr: [24785] (thread.c:302) femon receiver thread started (pid=23224, tid=24785)
Apr 16 23:11:46 linux-qgjx vdr: [24779] (ringbuffer.c:49) buffer usage: 70% (tid=24778)
Apr 16 23:11:46 linux-qgjx vdr: [24779] (ringbuffer.c:49) buffer usage: 80% (tid=24778)
Apr 16 23:11:46 linux-qgjx vdr: [24779] (ringbuffer.c:49) buffer usage: 90% (tid=24778)
Apr 16 23:11:46 linux-qgjx vdr: [24779] (ringbuffer.c:49) buffer usage: 100% (tid=24778)
Apr 16 23:11:48 linux-qgjx vdr: [24779] (device.c:1578) ERROR: driver buffer overflow on device 2
Apr 16 23:12:07 linux-qgjx syslog-ng[2640]: last message repeated 13 times
Apr 16 23:12:07 linux-qgjx vdr: [24778] (device.c:1606) ERROR: skipped 11 bytes to sync on TS packet on device 2
Apr 16 23:12:07 linux-qgjx vdr: [24779] (ringbuffer.c:49) buffer usage: 50% (tid=24778)
Apr 16 23:13:51 linux-qgjx vdr: [23236] (epg.c:164) channel 8 (kabel eins) event Don 16.04.2009 23:14-00:13 'K1 Doku' status 2
Apr 16 23:14:20 linux-qgjx vdr: [23236] (epg.c:164) channel 8 (kabel eins) event Don 16.04.2009 23:14-00:13 'K1 Doku' status 4
Apr 16 23:14:31 linux-qgjx vdr: [23236] (epg.c:164) channel 4 (SAT 1) event Don 16.04.2009 23:15-00:15 'Navy CIS' status 2
Apr 16 23:14:50 linux-qgjx vdr: [24783] (thread.c:310) femon osd thread ended (pid=23224, tid=24783)
Apr 16 23:14:50 linux-qgjx vdr: [24785] (thread.c:310) femon receiver thread ended (pid=23224, tid=24785)
Apr 16 23:14:52 linux-qgjx vdr: [23224] (device.c:588) switching to channel 4
Apr 16 23:14:52 linux-qgjx vdr: [24779] (ringbuffer.c:49) buffer usage: 70% (tid=24778)
Apr 16 23:14:53 linux-qgjx vdr: [24778] (transfer.c:51) ERROR: TS packet not accepted in Transfer Mode
Apr 16 23:14:53 linux-qgjx vdr: [24779] (ringbuffer.c:49) buffer usage: 0% (tid=24778)
Apr 16 23:14:55 linux-qgjx vdr: [23224] (device.c:588) switching to channel 3
Apr 16 23:15:00 linux-qgjx vdr: [23236] (epg.c:164) channel 4 (SAT 1) event Don 16.04.2009 23:15-00:15 'Navy CIS' status 4
Apr 16 23:15:02 linux-qgjx vdr: [23224] (device.c:588) switching to channel 4
Apr 16 23:15:05 linux-qgjx vdr: [24779] (ringbuffer.c:49) buffer usage: 70% (tid=24778)
Apr 16 23:15:05 linux-qgjx vdr: [24779] (ringbuffer.c:49) buffer usage: 80% (tid=24778)
Apr 16 23:15:06 linux-qgjx vdr: [24779] (ringbuffer.c:49) buffer usage: 90% (tid=24778)
Apr 16 23:15:06 linux-qgjx vdr: [24779] (ringbuffer.c:49) buffer usage: 100% (tid=24778)
Apr 16 23:15:09 linux-qgjx vdr: [24779] (device.c:1578) ERROR: driver buffer overflow on device 2
Apr 16 23:15:13 linux-qgjx vdr: [24778] (transfer.c:51) ERROR: TS packet not accepted in Transfer Mode
Apr 16 23:15:14 linux-qgjx vdr: [24778] (device.c:1606) ERROR: skipped 11 bytes to sync on TS packet on device 2
Apr 16 23:15:43 linux-qgjx vdr: [23243] (outputserial.c:770) Aurora: size=2359158, speed=3931 Byte/s
Apr 16 23:15:52 linux-qgjx vdr: [24779] (ringbuffer.c:49) buffer usage: 60% (tid=24778)
Apr 16 23:15:56 linux-qgjx vdr: [24779] (ringbuffer.c:49) buffer usage: 70% (tid=24778)
Apr 16 23:15:56 linux-qgjx vdr: [24779] (ringbuffer.c:49) buffer usage: 60% (tid=24778)
Apr 16 23:15:57 linux-qgjx vdr: [24779] (ringbuffer.c:49) buffer usage: 70% (tid=24778)
Apr 16 23:16:00 linux-qgjx vdr: [24779] (ringbuffer.c:49) buffer usage: 60% (tid=24778)
Apr 16 23:16:00 linux-qgjx vdr: [24779] (ringbuffer.c:49) buffer usage: 70% (tid=24778)
Apr 16 23:16:00 linux-qgjx vdr: [24779] (ringbuffer.c:49) buffer usage: 60% (tid=24778)
Apr 16 23:16:00 linux-qgjx vdr: [24779] (ringbuffer.c:49) buffer usage: 70% (tid=24778)
Apr 16 23:16:00 linux-qgjx vdr: [24779] (ringbuffer.c:49) buffer usage: 60% (tid=24778)

Auch wenn einfach nur TV geschaut wir, häufen sich Meldungen zur 'Buffer usage':

Apr 16 23:14:53 linux-qgjx vdr: [24778] (transfer.c:51) ERROR: TS packet not accepted in Transfer Mode
Apr 16 23:14:53 linux-qgjx vdr: [24779] (ringbuffer.c:49) buffer usage: 0% (tid=24778)
Apr 16 23:14:55 linux-qgjx vdr: [23224] (device.c:588) switching to channel 3
Apr 16 23:15:00 linux-qgjx vdr: [23236] (epg.c:164) channel 4 (SAT 1) event Don 16.04.2009 23:15-00:15 'Navy CIS' status 4
Apr 16 23:15:02 linux-qgjx vdr: [23224] (device.c:588) switching to channel 4
Apr 16 23:15:05 linux-qgjx vdr: [24779] (ringbuffer.c:49) buffer usage: 70% (tid=24778)
Apr 16 23:15:05 linux-qgjx vdr: [24779] (ringbuffer.c:49) buffer usage: 80% (tid=24778)
Apr 16 23:15:06 linux-qgjx vdr: [24779] (ringbuffer.c:49) buffer usage: 90% (tid=24778)
Apr 16 23:15:06 linux-qgjx vdr: [24779] (ringbuffer.c:49) buffer usage: 100% (tid=24778)
Apr 16 23:15:09 linux-qgjx vdr: [24779] (device.c:1578) ERROR: driver buffer overflow on device 2
Apr 16 23:15:13 linux-qgjx vdr: [24778] (transfer.c:51) ERROR: TS packet not accepted in Transfer Mode
Apr 16 23:15:14 linux-qgjx vdr: [24778] (device.c:1606) ERROR: skipped 11 bytes to sync on TS packet on device 2
Apr 16 23:15:43 linux-qgjx vdr: [23243] (outputserial.c:770) Aurora: size=2359158, speed=3931 Byte/s
Apr 16 23:15:52 linux-qgjx vdr: [24779] (ringbuffer.c:49) buffer usage: 60% (tid=24778)
Apr 16 23:15:56 linux-qgjx vdr: [24779] (ringbuffer.c:49) buffer usage: 70% (tid=24778)
Apr 16 23:15:56 linux-qgjx vdr: [24779] (ringbuffer.c:49) buffer usage: 60% (tid=24778)
Apr 16 23:15:57 linux-qgjx vdr: [24779] (ringbuffer.c:49) buffer usage: 70% (tid=24778)
Apr 16 23:16:00 linux-qgjx vdr: [24779] (ringbuffer.c:49) buffer usage: 60% (tid=24778)
Apr 16 23:16:00 linux-qgjx vdr: [24779] (ringbuffer.c:49) buffer usage: 70% (tid=24778)
Apr 16 23:16:00 linux-qgjx vdr: [24779] (ringbuffer.c:49) buffer usage: 60% (tid=24778)
Apr 16 23:16:00 linux-qgjx vdr: [24779] (ringbuffer.c:49) buffer usage: 70% (tid=24778)
Apr 16 23:16:00 linux-qgjx vdr: [24779] (ringbuffer.c:49) buffer usage: 60% (tid=24778)
Apr 16 23:16:00 linux-qgjx vdr: [24779] (ringbuffer.c:49) buffer usage: 70% (tid=24778)
Apr 16 23:16:01 linux-qgjx vdr: [24779] (ringbuffer.c:49) buffer usage: 60% (tid=24778)
Apr 16 23:16:06 linux-qgjx vdr: [24779] (ringbuffer.c:49) buffer usage: 70% (tid=24778)
Apr 16 23:16:06 linux-qgjx vdr: [24779] (ringbuffer.c:49) buffer usage: 60% (tid=24778)
Apr 16 23:16:06 linux-qgjx vdr: [24779] (ringbuffer.c:49) buffer usage: 70% (tid=24778)
Apr 16 23:16:06 linux-qgjx vdr: [24779] (ringbuffer.c:49) buffer usage: 60% (tid=24778)
Apr 16 23:16:06 linux-qgjx vdr: [24779] (ringbuffer.c:49) buffer usage: 70% (tid=24778)
Apr 16 23:16:06 linux-qgjx vdr: [24779] (ringbuffer.c:49) buffer usage: 60% (tid=24778)
Apr 16 23:16:06 linux-qgjx vdr: [24779] (ringbuffer.c:49) buffer usage: 70% (tid=24778)
Apr 16 23:16:07 linux-qgjx vdr: [24779] (ringbuffer.c:49) buffer usage: 80% (tid=24778)
Apr 16 23:16:09 linux-qgjx vdr: [24779] (ringbuffer.c:49) buffer usage: 90% (tid=24778)
Apr 16 23:16:13 linux-qgjx vdr: [24779] (ringbuffer.c:49) buffer usage: 60% (tid=24778)
Apr 16 23:16:13 linux-qgjx vdr: [24779] (ringbuffer.c:49) buffer usage: 70% (tid=24778)
Apr 16 23:16:13 linux-qgjx vdr: [24779] (ringbuffer.c:49) buffer usage: 60% (tid=24778)
Apr 16 23:16:18 linux-qgjx vdr: [24779] (ringbuffer.c:49) buffer usage: 70% (tid=24778)
Apr 16 23:16:18 linux-qgjx vdr: [24779] (ringbuffer.c:49) buffer usage: 60% (tid=24778)
Apr 16 23:16:18 linux-qgjx vdr: [24779] (ringbuffer.c:49) buffer usage: 70% (tid=24778)
Apr 16 23:16:19 linux-qgjx vdr: [24779] (ringbuffer.c:49) buffer usage: 60% (tid=24778)
Apr 16 23:16:19 linux-qgjx vdr: [24779] (ringbuffer.c:49) buffer usage: 70% (tid=24778)
Apr 16 23:16:19 linux-qgjx vdr: [24779] (ringbuffer.c:49) buffer usage: 60% (tid=24778)
Apr 16 23:16:19 linux-qgjx vdr: [24779] (ringbuffer.c:49) buffer usage: 70% (tid=24778)
Apr 16 23:16:19 linux-qgjx vdr: [24779] (ringbuffer.c:49) buffer usage: 60% (tid=24778)
Apr 16 23:16:20 linux-qgjx vdr: [24779] (ringbuffer.c:49) buffer usage: 70% (tid=24778)
Apr 16 23:16:20 linux-qgjx vdr: [24779] (ringbuffer.c:49) buffer usage: 60% (tid=24778)
Apr 16 23:16:20 linux-qgjx vdr: [24779] (ringbuffer.c:49) buffer usage: 70% (tid=24778)
Apr 16 23:16:20 linux-qgjx vdr: [24779] (ringbuffer.c:49) buffer usage: 60% (tid=24778)
Apr 16 23:16:20 linux-qgjx vdr: [24779] (ringbuffer.c:49) buffer usage: 70% (tid=24778)
Apr 16 23:16:20 linux-qgjx vdr: [24779] (ringbuffer.c:49) buffer usage: 60% (tid=24778)
Apr 16 23:16:20 linux-qgjx vdr: [24779] (ringbuffer.c:49) buffer usage: 70% (tid=24778)
Apr 16 23:16:20 linux-qgjx vdr: [24779] (ringbuffer.c:49) buffer usage: 60% (tid=24778)
Apr 16 23:16:25 linux-qgjx vdr: [24779] (ringbuffer.c:49) buffer usage: 70% (tid=24778)
Apr 16 23:16:25 linux-qgjx vdr: [24779] (ringbuffer.c:49) buffer usage: 60% (tid=24778)
Apr 16 23:16:25 linux-qgjx vdr: [24779] (ringbuffer.c:49) buffer usage: 70% (tid=24778)
Apr 16 23:16:25 linux-qgjx vdr: [24779] (ringbuffer.c:49) buffer usage: 60% (tid=24778)
Apr 16 23:16:25 linux-qgjx vdr: [24779] (ringbuffer.c:49) buffer usage: 70% (tid=24778)
Apr 16 23:16:25 linux-qgjx vdr: [24779] (ringbuffer.c:49) buffer usage: 60% (tid=24778)
Apr 16 23:16:25 linux-qgjx vdr: [24779] (ringbuffer.c:49) buffer usage: 70% (tid=24778)
Apr 16 23:16:27 linux-qgjx vdr: [24779] (ringbuffer.c:49) buffer usage: 80% (tid=24778)

System bei VDR 1.7.4:
DVB-Treiber nach aktuellen Repository von LinuxTV, gepatcht entsprechend Olivers Refactoring-Änderungen (Stand von vor ca. 6 Monaten) und dem TS-Mode-Patch entsprechend http://linuxtv.org/hg/~endriss/v4l-dvb/raw-rev/55fa4f709cf2 (war irgendwo mal als Diff verfügbar). Ich verwende noch eine Reihe anderer Patches, die aber mit dem Problem nichts zu tun haben (sollten). Firmware für die FF-Karte war f12623.

System bei Vdr 1.7.5:
DVB-Treiber wie bei 1.7.4, aber um http://linuxtv.org/hg/~endriss/v4l-dvb/raw-rev/b5567f27fba7 erweitert. Firmware ist fe2624.

Der VDR ist in beiden Varianten mit meinem GrabImage- und dem MainMenuHooks-Patch, der bei eggsearch dabei ist, verpatcht.

Bei VDR 1.7.4 gibt es die oben geschilderten Probleme nicht. Ich habe gelegentlich Probleme mit der Sychronisation zwischen Bild und Ton, wenn die FF im Transfermode betrieben wird (bei Wiedergabe von Aufnahmen und im Live-Mode). Es gibt auch einige Aufnahmen, bei denen die Wiedergabe an bestimmten Stellen einfach stehen bleibt.

Zum Testen werde ich mal mit dem VDR auf 1.7.4 zurück gehen, aber DVB-Treiber und Firmware unverändert lassen.

Gruß
e9hack

Zitat

Original von e9hack
Zum Testen werde ich mal mit dem VDR auf 1.7.4 zurück gehen, aber DVB-Treiber und Firmware unverändert lassen.

VDR 1.7.4 zeigt bei unveränderten DVB-Treibern die gleichen Probleme. Unveränderte DVB-Treiber und alte Firmware ändert auch nichts. Zurücknehmen von http://linuxtv.org/hg/~endriss/v4l-dvb/raw-rev/b5567f27fba7 (und alte Firmware) beseitigt das Problem. Irgendwas an dem Patch ist faul.

Gruß
e9hack

vielleicht das gleiche Grundproblem, das ich hier beschrieben habe?
[ANNOUNCE] VDR developer version 1.7.5

Zitat

Original von kls

Das ist zumindest das, was ich vom Autor bekomen habe.
Fehlermeldungen bitte direkt an ihn

(Es lebe 7-Bit ASCII - wer auch immer dieses UTF-8 Zeugs erfunden hat, möge furchtbare Qualen erleiden...

Klaus

Alles anzeigen

Hab bei Diego mal angefragt, ob das so passt. Die Antwort steht noch aus.

Zitat

Original von Papablues

Eben, wer braucht schon die komischen Zeichen die sollen alle mal ne vernünftige schrift lernen
Zu GSM zeiten hat doch 7 bit vollkommen gereicht

SCNR

fab

Alles anzeigen

Die Zeichen gibt es alle auch in iso8859-15
http://de.wikipedia.org/wiki/ISO_8859-15

Gruß
Marc

Zitat

Original von e9hack

VDR 1.7.4 zeigt bei unveränderten DVB-Treibern die gleichen Probleme. Unveränderte DVB-Treiber und alte Firmware ändert auch nichts. Zurücknehmen von http://linuxtv.org/hg/~endriss/v4l-dvb/raw-rev/b5567f27fba7 (und alte Firmware) beseitigt das Problem. Irgendwas an dem Patch ist faul.

Für die Probleme kann allein der zweite Patch verantwortlich sein:
- Firmwareänderungen in fe2624 betreffen ausschließlich die STC-Behandlung.
- Der erste Patch fügt lediglich TS-Wiedergabe hinzu.

Beides wird von älteren VDR-Versionen nicht verwendet, d.h. weder die neue Firmware noch der erste Patch sollte ältere VDR-Versionen in irgendeiner Weise beeinflussen.

e9hack
Hilft es, wenn man in av7110.h AVOUTLEN auf (1024*1024) vergrößert?
(Patch für mein Repository ist angehängt.)

Eigentlich wollte ich Änderungen der Puffergröße vermeiden, da hierdurch das Setzen von Schnittmarken mit älteren VDR-Versionen ungenauer wird. Denn VDR ist auf die alte Puffergröße abgestimmt.

Scheint jedoch notwendig zu sein, denn z.B. beim Wechsel von 00001.ts zu 00002.ts habe ich ohne diese Änderung reproduzierbar Ruckler bei der Wiedergabe. Die Aufnahmen selbst sind einwandfrei. Sieht so aus, als ob dem Decoder kurzzeitig die Daten ausgehen.

CU
Oliver

Zitat

Original von UFO
Für die Probleme kann allein der zweite Patch verantwortlich sein:
- Firmwareänderungen in fe2624 betreffen ausschließlich die STC-Behandlung.
- Der erste Patch fügt lediglich TS-Wiedergabe hinzu.

Ich habe noch einen Patch unterschlagen, der in Kombination mit dem zweiten Patch das Problem verursacht. Ich hatte mal den audiobuff-Patch von hier getestet. Der war immer noch drin. Wenn ich den rauswerfe (ich bin über AVOUTLEN darauf gestoßen), kommen die Fehler nicht.

Gruß
e9hack

Zitat

Original von e9hack

Ich habe noch einen Patch unterschlagen, der in Kombination mit dem zweiten Patch das Problem verursacht. Ich hatte mal den audiobuff-Patch von hier getestet. Der war immer noch drin. Wenn ich den rauswerfe (ich bin über AVOUTLEN darauf gestoßen), kommen die Fehler nicht.

Ok, das erklärt einiges. Dieser Patch muß auf jeden Fall raus.

CU
Oliver

Zitat

Original von Torsten73
- Der Support für eine Skystar HD2 würde mich auch interessieren. Warum wird nur der v4l unterstützt und nicht mehr die anderen Treiber? ODer kann sich das noch ändern?

Also meine SkyStar HD2 läuft problemlos mit 1.7.5 und s2-liplianin

Und mein Netceiver auch

Ich glaube die Timestamps sind aber trotzdem noch nicht so richtig (habe die tools.h schon entsprechend abgeändert). Die Aufnahmeübersicht zeigt zB bei einer knapp 2h Aufnahme 6:38 an und VLC zeigt Überhaupt gar keine Zeitstempel beim abspielen (getestet mit einer h264 HD Aufnahme, werde mal noch andere testen)

Zitat

Originally posted by Dr. Seltsam

danke, das werde ich mir mal anschauen.

Noch ein paar Fragen/Anregungen:

Die PLUGINS.html ist glaube ich nicht ganz aktuell?

Mir fiel auf alle Fälle auf, dass

Code

virtual int NumProvidedSystems(void) const;

dort nicht aufgeführt ist, obwohl devices es brauchen. Ohne es im pvrinput-plugin zu deklarieren, kommt beim Umschalten auf einen pvrinput-Kanal:
ERROR: device 10 reported an invalid number (0) of supported delivery systems - assuming 1

Alles anzeigen

Sorry, das hatte ich tatsächlich übersehen. Hab's für die 1.7.6 hinzugefügt.

Zitat

Wie ist es bei den Ausgabe-Plugins? Einzige Änderung laut PLUGINS.html ist

Code

virtual bool IsPlayingVideo(void) const;

Ist das noch aktuell? Ich meine, dass bei den letzten Versionen allerlei weitere Funktionen hinzugekommen sind, aber bei den vielen Änderungen habe ich total den Durchblick verloren.

Streng genommen ist das gar keine unbedingt zu implementierende Funktion, da sie ein sinnvolles Default-Verhalten hat. Aber es stimmt schon, wenn man eine Information an mehr als einer Stelle hat, wird sie an mindesten einer Stelle falsch oder unvollständig sein. Im Zweifelsfall einfach immer im jeweiligen Sourcecode nachschauen, da steht die ultimative Referenz

Klaus

Zitat

Original von Papablues

Eben, wer braucht schon die komischen Zeichen die sollen alle mal ne vernünftige schrift lernen
Zu GSM zeiten hat doch 7 bit vollkommen gereicht

Dann muesste es aber doch so heissen:

(Es lebe 7-Bit ASCII - wer auch immer dieses UTF-8 Zeugs erfunden hat, m"oge furchtbare Qualen erleiden... ;-)

Gruss,
- berndl

Zitat

Originally posted by UFO
Eigentlich wollte ich Änderungen der Puffergröße vermeiden, da hierdurch das Setzen von Schnittmarken mit älteren VDR-Versionen ungenauer wird. Denn VDR ist auf die alte Puffergröße abgestimmt.

Scheint jedoch notwendig zu sein, denn z.B. beim Wechsel von 00001.ts zu 00002.ts habe ich ohne diese Änderung reproduzierbar Ruckler bei der Wiedergabe. Die Aufnahmen selbst sind einwandfrei. Sieht so aus, als ob dem Decoder kurzzeitig die Daten ausgehen.

Die Störungen beim File-Übergang habe ich hier auch gesehen und mir daraufhin mal cDvbPlayer::Action() genauer angeschaut. Durch meine jüngsten Änderungen hatte sich da anscheinend ergeben, daß er immer nur genau einen Frame gelesen und dann diesen ans Device geschickt hat. Er hatte also keinen "Vorsprung" mehr, und somit gingen ihm die Daten aus wenn auf die nächste Datei weitergeschaltet wurde, was ja auch etwas Zeit kostet.

Probier' bitte mal folgenden Patch:

--- dvbplayer.c 2009/04/13 11:10:50     2.12
+++ dvbplayer.c 2009/04/18 14:18:22
@@ -398,17 +398,15 @@
   int LastReadIFrame = -1;
   int SwitchToPlayFrame = 0;


-  while (Running() && (NextFile() || readIndex >= 0 || ringBuffer->Available())) {
-        if (Sleep) {
+  while (Running()) {
            if (WaitingForData)
               nonBlockingFileReader->WaitForDataMs(3); // this keeps the CPU load low, but reacts immediately on new data
-           else
-              cCondWait::SleepMs(3); // this keeps the CPU load low
+        else if (Sleep) {
+           cPoller Poller;
+           DevicePoll(Poller, 10);
            Sleep = false;
            }
-        cPoller Poller;
-        if (DevicePoll(Poller, 100)) {
-
+        {
            LOCK_THREAD;


            // Read the next frame from the file:
@@ -493,6 +491,8 @@
               if (readFrame) {
                  if (ringBuffer->Put(readFrame))
                     readFrame = NULL;
+                else
+                   Sleep = true;
                  }
               }
            else
@@ -538,6 +538,8 @@
                     }
                  else if (w < 0 && FATALERRNO)
                     LOG_ERROR;
+                else
+                   Sleep = true;
                  }
               if (pc <= 0) {
                  if (!eof || (playDir != pdForward && playFrame->Index() > 0) || (playDir == pdForward && playFrame->Index() < readIndex))

Die Einrückungen stimmen damit noch nicht, aber um den Patch klein zu halten habe ich ihn mit -bw gemacht (in der 1.7.6 passt es dann schon wieder).

Klaus

Zitat

Originally posted by zulu
Nach dem Extensions-Patch kommt jetzt so was für à, è und ò:

Code

msgmerge -U --no-wrap --no-location --backup=none -q po/it_IT.po po/vdr.pot
po/it_IT.po:101:29: ungültige Multibyte-Sequenz
po/it_IT.po:218:15: ungültige Multibyte-Sequenz
...
make: *** [po/it_IT.po] Fehler 1

Diego hat wohl den Zeichensatz von ISO-8859-15 auf UTF-8 geändert.
Evtl. liegt da der Hund begraben.
Ich wüsste jedenfalls nicht, was ich hier ändern sollte...

Klaus

Zitat

Original von kls

Die Störungen beim File-Übergang habe ich hier auch gesehen und mir daraufhin mal cDvbPlayer::Action() genauer angeschaut. Durch meine jüngsten Änderungen hatte sich da anscheinend ergeben, daß er immer nur genau einen Frame gelesen und dann diesen ans Device geschickt hat. Er hatte also keinen "Vorsprung" mehr, und somit gingen ihm die Daten aus wenn auf die nächste Datei weitergeschaltet wurde, was ja auch etwas Zeit kostet.

Probier' bitte mal folgenden Patch:
...

Die Einrückungen stimmen damit noch nicht, aber um den Patch klein zu halten habe ich ihn mit -bw gemacht (in der 1.7.6 passt es dann schon wieder).

Alles anzeigen

Sieht gut aus. Damit ist das Problem beim Dateiwechsel gelöst. Danke!

CU
Oliver

Zitat

Original von UFO

Ok, das erklärt einiges. Dieser Patch muß auf jeden Fall raus.

Das wars doch nicht. Ich hatte wieder ein ähnliches Verhalten. Um 20:10 bzw. 20:15 sind zwei Aufnahmen losgelaufen. Es wurde gleichzeitig Fernsehen geschaut. Als um 20:15 die zweite Aufnahme gestartet ist, ist das Bild schwarz geworden mit der Info 'Aufnahme beginnt in kürze!'. Das Bild blieb für ca. 30sec so und der VDR hat scheinbar auf keine Taste der Fernbedienung reagiert. Im Log läuft der Transferbuffer voll und es findet sich die Meldung 'ERROR: TS packet not accepted in Transfer Mode'. Irgendwann kam das Bild wieder und es konnte der Film geschaut werden. Irgendwann kam dann die erste Werbepause. Beim Zappen hing der der VDR für ca. 1min bei schwarzem Bild. Im Log läuft wieder der Transferbuffer voll und es gibt mehrfach die Meldung 'ERROR: driver buffer overflow on device 2'. Device 1 ist meine TT-C2300 und Device 2 eine Cinergy 1200C. Es gibt dann noch die Meldung 'ERROR: skipped 11 bytes to sync on TS packet on device 2'. Ab dem Zeitpunkt ist dann der Transferbuffer dauerhaft am Überlaufen. Beim nächsten Zappen während der Werbung gibts wieder Fehlermeldungen. Das Bild kommt jedoch innerhalb kurzer Zeit. Irgendwann habe ich dan auch mal femon gestartet. Es hat knapp eine Minute bis zur Anzeige gebraucht.

Ich habe mal das Log ab VDR-Start angehängt.

Das merkwürdige Verhalten gibts erst seit 1.7.5. Mit 1.7.4 ist mir da nichts aufgefallen.

Gruß
e9hack

Zitat

Original von kls

Diego hat wohl den Zeichensatz von ISO-8859-15 auf UTF-8 geändert.
Evtl. liegt da der Hund begraben.
Ich wüsste jedenfalls nicht, was ich hier ändern sollte...

Klaus

Diego hat sich gemeldet und seinem Mail nach, hat er genau das getan.
Er hat die Übersetzungen (samt meinen Anpassungen für den neuen Ext-Patch) auch nochmal im OSD geprüft, und alle Zeichen werden richtig dargestellt.

Gruß
Marc

PS: Warum die Sonderzeichen jetzt im Code so merkwürdig dargestellt werden, verstehe ich trotzdem nicht.

Zitat

Original von e9hack

Das wars doch nicht. Ich hatte wieder ein ähnliches Verhalten. Um 20:10 bzw. 20:15 sind zwei Aufnahmen losgelaufen. Es wurde gleichzeitig Fernsehen geschaut. Als um 20:15 die zweite Aufnahme gestartet ist, ist das Bild schwarz geworden mit der Info 'Aufnahme beginnt in kürze!'. Das Bild blieb für ca. 30sec so und der VDR hat scheinbar auf keine Taste der Fernbedienung reagiert. Im Log läuft der Transferbuffer voll und es findet sich die Meldung 'ERROR: TS packet not accepted in Transfer Mode'. Irgendwann kam das Bild wieder und es konnte der Film geschaut werden. Irgendwann kam dann die erste Werbepause. Beim Zappen hing der der VDR für ca. 1min bei schwarzem Bild. Im Log läuft wieder der Transferbuffer voll und es gibt mehrfach die Meldung 'ERROR: driver buffer overflow on device 2'. Device 1 ist meine TT-C2300 und Device 2 eine Cinergy 1200C. Es gibt dann noch die Meldung 'ERROR: skipped 11 bytes to sync on TS packet on device 2'. Ab dem Zeitpunkt ist dann der Transferbuffer dauerhaft am Überlaufen. Beim nächsten Zappen während der Werbung gibts wieder Fehlermeldungen. Das Bild kommt jedoch innerhalb kurzer Zeit. Irgendwann habe ich dan auch mal femon gestartet. Es hat knapp eine Minute bis zur Anzeige gebraucht.

Ich habe mal das Log ab VDR-Start angehängt.

Das merkwürdige Verhalten gibts erst seit 1.7.5. Mit 1.7.4 ist mir da nichts aufgefallen.

Alles anzeigen

Dem Log kann ich nichts wirklich Brauchbares entnehmen.

Teste bitte einmal folgende Varianten durch:
a) den originalen Treiber aus meinem Repository
b) Vergrößerung des Video-Puffers auf 1MByte (wie oben beschrieben)
c) neue Firmware + Treiber ohne den zweiten Patch http://linuxtv.org/hg/~endriss/v4l-dvb/raw-rev/b5567f27fba7

CU
Oliver

Zitat

Original von UFO
Teste bitte einmal folgende Varianten durch:
a) den originalen Treiber aus meinem Repository

Damit gibt es die Probleme nicht, außer der Fehlermeldung 'ERROR: TS packet not accepted in Transfer Mode' beim Kanalwechsel.

Wenn meine FF im Transfermode bei hohen Bitraten arbeitet, gibt es Aussetzer und der VDR reagiert auf jeden Tastendruck auf der FB mit 10sec Verzögerung. Der VDR ist so nicht benutzbar. Ich habe mir die Optimierungen aus Deinem FullTs/Refactoring-Repository in den Main-Zweig eingebaut. Das läuft seit ca. einem Jahr problemlos. Meine FF schafft dann auch ARD bzw. ZDF bei 8 MBit/s problemlos im Transfermode.

Mit den letzten Änderungen für VDR 1.7.5 gibt es die bereits beschriebenen Probleme.

Irgendwie sieht es so aus, als würde die FF (bzw. der Treiber) nach Start der Wiedergabe die gesendeten Daten für kurze Zeit nicht oder nur verzögert annehmen können. Bei hohen Bitraten läuft dann der Buffer im VDR voll, der ja weiter gefüllt wird.

Gruß
e9hack