You are not logged in.
VDR Portal »
News »
News-Archiv »Dear visitor, welcome to VDR Portal. If this is your first visit here, please read the Help. It explains in detail how this page works. To use all features of this page, you should consider registering. Please use the registration form, to register here or read more information about the registration process. If you are already registered, please login here.
Thursday, April 16th 2009, 2:00pm
Quoted
Original von kls
(Es lebe 7-Bit ASCII - wer auch immer dieses UTF-8 Zeugs erfunden hat, möge furchtbare Qualen erleiden... ;-)
Thursday, April 16th 2009, 2:03pm
This post has been edited 1 times, last edit by "Torsten73" (Apr 16th 2009, 2:03pm)
Friday, April 17th 2009, 1:01am
|
Source code |
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 |
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) |
|
|
Source code |
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 |
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) |
Friday, April 17th 2009, 1:40am
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.
Friday, April 17th 2009, 8:29am
Friday, April 17th 2009, 10:14am
Original von kls
Originally posted by zulu
...
Ist das Absicht?
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
Original von Papablues
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
Friday, April 17th 2009, 1:17pm
Original von e9hack
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.
This post has been edited 2 times, last edit by "UFO" (Apr 17th 2009, 1:21pm)
Friday, April 17th 2009, 5:25pm
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.
Friday, April 17th 2009, 5:50pm
Original von e9hack
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.
Friday, April 17th 2009, 8:29pm
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?
Saturday, April 18th 2009, 12:00pm
Originally posted by Dr. Seltsam
Original von kls
Könnte schon sein, daß das ohne die remux-Änderungen geht, denn das funktioniert ja auch für alte Aufnahmen in PES.
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
dort nicht aufgeführt ist, obwohl devices es brauchen. Ohne es im pvrinput-plugin zu deklarieren, kommt beim Umschalten auf einen pvrinput-Kanal:
Source code
ERROR: device 10 reported an invalid number (0) of supported delivery systems - assuming 1
Wie ist es bei den Ausgabe-Plugins? Einzige Änderung laut PLUGINS.html ist
Source code
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.
Saturday, April 18th 2009, 1:27pm
Original von Papablues
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
|
|
Source code |
1 |
(Es lebe 7-Bit ASCII - wer auch immer dieses UTF-8 Zeugs erfunden hat, m"oge furchtbare Qualen erleiden... ;-) |
Saturday, April 18th 2009, 4:27pm
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.
|
|
Source code |
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 |
--- 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))
|
Saturday, April 18th 2009, 5:12pm
Originally posted by zulu
Nach dem Extensions-Patch kommt jetzt so was für à, è und ò:
Source code
Sunday, April 19th 2009, 12:24am
Original von kls
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:
...
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).
Sunday, April 19th 2009, 9:43pm
Original von UFO
Ok, das erklärt einiges. Dieser Patch muß auf jeden Fall raus.
Original von e9hack
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.
Tuesday, April 21st 2009, 10:34am
Original von kls
Originally posted by zulu
Nach dem Extensions-Patch kommt jetzt so was für à, è und ò:
Source code
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
Tuesday, April 21st 2009, 8:00pm
Original von e9hack
Original von UFO
Ok, das erklärt einiges. Dieser Patch muß auf jeden Fall raus.
Original von e9hack
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.
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.
Thursday, April 23rd 2009, 10:03pm
Original von UFO
Teste bitte einmal folgende Varianten durch:
a) den originalen Treiber aus meinem Repository
Thursday, June 20th 2013, 6:46am
Go to the top of the page
