You are not logged in.

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.

Papablues

Intermediate

Posts: 206

Location: Lower franconia

Occupation: SDevel

  • Send private message

41

Thursday, April 16th 2009, 2:00pm

:ot

Quoted

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

:uglyhammer

SCNR

fab
Debian server [ AMD Athlon(tm) 64 Processor 3000+ 3*Nova SE2 1* FF muss nachschauen CI + alphacrypt Soft raid5 549G]
Clients [2 * MVP mit vomp 1 * MacBook Pro VLC streaming 1 * VOMP for windows]

Posts: 1,778

Occupation: Radio Fernsehtechniker

  • Send private message

42

Thursday, April 16th 2009, 2:03pm

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?
Yavdr 0.5: KVM Server mit YAVDR als Host, Tyan Xeon Server, Virtualbox + KVM
Yavdr 0.5: Asus AT5iont-t, ION2, 4GB Ram, Momentus 2,5" 500GB, HEX TFX 300W 82+, Cine S2 V6.2 , 38W max.
Yavdr 0.5:
Zotac D2550ITXS-A-E mit GT610 OB, TT S2-4100 PCI-e ,Joujye NU-0568I-B
Yavdr 0.5:
Sandy Bridge G840, Tests und Energieverbrauch , CoHaus CIR, Cine S2 V6.2
MLD RasPi

This post has been edited 1 times, last edit by "Torsten73" (Apr 16th 2009, 2:03pm)


e9hack

Professional

Posts: 1,641

Location: BW in der Nähe von Esslingen

  • Send private message

43

Friday, April 17th 2009, 1:01am

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:

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)


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

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)


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

e9hack

Professional

Posts: 1,641

Location: BW in der Nähe von Esslingen

  • Send private message

44

Friday, April 17th 2009, 1:40am

Quoted

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

Dr. Seltsam

Im Forum Zuhause

Posts: 9,984

Location: 3. Planet des Sonnensystems

Occupation: Organisator

  • Send private message

45

Friday, April 17th 2009, 8:29am

vielleicht das gleiche Grundproblem, das ich hier beschrieben habe?
[ANNOUNCE] VDR developer version 1.7.5
VDR 1: Silverstone LC20, Cougar A300/R, MSI C847MS-E33, passive Asus GT520, KNC One DVB-C, Cine CT V6, WD10EACS; Atric-IR-Einschalter. SW: yavdr 0.5 per SSD
VDR 2: im Aufbau: ACT-620 mit Coba-NT, Asrock B75 Pro3-M, Celeron G540, Sundtek MediaTV Digital Home (DVB-C/T), passive Asus GT610. SW: Ubuntu 13.04 minimal (ohne grafische Oberfläche) per SSD

46

Friday, April 17th 2009, 10:14am

Quoted

Original von kls

Quoted

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


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

Quoted

Original von Papablues
:ot

Quoted

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

:uglyhammer

SCNR

fab


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

Gruß
Marc
>>>> x-vdr <<<< Installations-Skript für einen VDR mit Debian als Basis

UFO

Sage

Posts: 5,124

Location: Großherzogthum Baden

  • Send private message

47

Friday, April 17th 2009, 1:17pm

Test: Videopuffer im Treiber vergrößern

Quoted

Original von e9hack

Quoted

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.


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
UFO has attached the following file:
VDR Remote Control Plugin (Version 0.5.0): http://www.escape-edv.de/endriss/vdr
FAQ zum Remote Control Plugin: http://www.escape-edv.de/endriss/vdr/FAQ
Aktuelle Treiber: http://www.vdr-portal.de/board18-vdr-har…-s2-6400-teil-3
Full-TS-Mod für SD full-featured Karten: http://www.escape-edv.de/endriss/dvb-full-ts-mod bzw. hier
SDRAM-Erweiterung für SD full-featured Karten: http://www.escape-edv.de/endriss/dvb-mem-mod

This post has been edited 2 times, last edit by "UFO" (Apr 17th 2009, 1:21pm)


e9hack

Professional

Posts: 1,641

Location: BW in der Nähe von Esslingen

  • Send private message

48

Friday, April 17th 2009, 5:25pm

RE: Test: Videopuffer im Treiber vergrößern

Quoted

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

UFO

Sage

Posts: 5,124

Location: Großherzogthum Baden

  • Send private message

49

Friday, April 17th 2009, 5:50pm

RE: Test: Videopuffer im Treiber vergrößern

Quoted

Original von e9hack

Quoted

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.


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

CU
Oliver
VDR Remote Control Plugin (Version 0.5.0): http://www.escape-edv.de/endriss/vdr
FAQ zum Remote Control Plugin: http://www.escape-edv.de/endriss/vdr/FAQ
Aktuelle Treiber: http://www.vdr-portal.de/board18-vdr-har…-s2-6400-teil-3
Full-TS-Mod für SD full-featured Karten: http://www.escape-edv.de/endriss/dvb-full-ts-mod bzw. hier
SDRAM-Erweiterung für SD full-featured Karten: http://www.escape-edv.de/endriss/dvb-mem-mod

50

Friday, April 17th 2009, 8:29pm

Quoted

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 ;)
VDR: AMD A4-3400, 4096 MB RAM, Technisat SkyStar HD2, Technisat Skystar USB HD
openSUSE 13.1, VDR 2.0.4, vdr-xineliboutput

51

Friday, April 17th 2009, 9:13pm

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)

kls

Master

Posts: 2,682

Location: Mettenheim

  • Send private message

52

Saturday, April 18th 2009, 12:00pm

RE: [ANNOUNCE] VDR developer version 1.7.5

Quoted

Originally posted by Dr. Seltsam

Quoted

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

Source code

1
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


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

Quoted


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

Source code

1
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
Gib CI+/HD+ keine Chance! Lasst diese Pest am ausgestreckten Arm verhungern!
Wer für sowas bezahlt macht sich zum Totengräber von Projekten wie VDR!
Die Wahrheit ueber HD Plus
CI-Plus -- Das trojanische Pferd im Wohnzimmer

53

Saturday, April 18th 2009, 1:27pm

Quoted

Original von Papablues

Quoted

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

Dann muesste es aber doch so heissen:

Source code

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

Gruss,
- berndl

kls

Master

Posts: 2,682

Location: Mettenheim

  • Send private message

54

Saturday, April 18th 2009, 4:27pm

RE: Test: Videopuffer im Treiber vergrößern

Quoted

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:

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))


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
Gib CI+/HD+ keine Chance! Lasst diese Pest am ausgestreckten Arm verhungern!
Wer für sowas bezahlt macht sich zum Totengräber von Projekten wie VDR!
Die Wahrheit ueber HD Plus
CI-Plus -- Das trojanische Pferd im Wohnzimmer

kls

Master

Posts: 2,682

Location: Mettenheim

  • Send private message

55

Saturday, April 18th 2009, 5:12pm

Quoted

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

Source code

1
2
3
4
5
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
Gib CI+/HD+ keine Chance! Lasst diese Pest am ausgestreckten Arm verhungern!
Wer für sowas bezahlt macht sich zum Totengräber von Projekten wie VDR!
Die Wahrheit ueber HD Plus
CI-Plus -- Das trojanische Pferd im Wohnzimmer

UFO

Sage

Posts: 5,124

Location: Großherzogthum Baden

  • Send private message

56

Sunday, April 19th 2009, 12:24am

RE: Test: Videopuffer im Treiber vergrößern

Quoted

Original von kls

Quoted

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).


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

CU
Oliver
VDR Remote Control Plugin (Version 0.5.0): http://www.escape-edv.de/endriss/vdr
FAQ zum Remote Control Plugin: http://www.escape-edv.de/endriss/vdr/FAQ
Aktuelle Treiber: http://www.vdr-portal.de/board18-vdr-har…-s2-6400-teil-3
Full-TS-Mod für SD full-featured Karten: http://www.escape-edv.de/endriss/dvb-full-ts-mod bzw. hier
SDRAM-Erweiterung für SD full-featured Karten: http://www.escape-edv.de/endriss/dvb-mem-mod

e9hack

Professional

Posts: 1,641

Location: BW in der Nähe von Esslingen

  • Send private message

57

Sunday, April 19th 2009, 9:43pm

RE: Test: Videopuffer im Treiber vergrößern

Quoted

Original von UFO

Quoted

Original von e9hack

Quoted

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.
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
e9hack has attached the following file:
  • messages.bz2 (10.25 kB - 109 times downloaded - latest: Aug 14th 2014, 12:39pm)

58

Tuesday, April 21st 2009, 10:34am

Alles ist gut

Quoted

Original von kls

Quoted

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

Source code

1
2
3
4
5
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


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.
>>>> x-vdr <<<< Installations-Skript für einen VDR mit Debian als Basis

UFO

Sage

Posts: 5,124

Location: Großherzogthum Baden

  • Send private message

59

Tuesday, April 21st 2009, 8:00pm

RE: Test: Videopuffer im Treiber vergrößern

Quoted

Original von e9hack

Quoted

Original von UFO

Quoted

Original von e9hack

Quoted

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.
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.


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
VDR Remote Control Plugin (Version 0.5.0): http://www.escape-edv.de/endriss/vdr
FAQ zum Remote Control Plugin: http://www.escape-edv.de/endriss/vdr/FAQ
Aktuelle Treiber: http://www.vdr-portal.de/board18-vdr-har…-s2-6400-teil-3
Full-TS-Mod für SD full-featured Karten: http://www.escape-edv.de/endriss/dvb-full-ts-mod bzw. hier
SDRAM-Erweiterung für SD full-featured Karten: http://www.escape-edv.de/endriss/dvb-mem-mod

e9hack

Professional

Posts: 1,641

Location: BW in der Nähe von Esslingen

  • Send private message

60

Thursday, April 23rd 2009, 10:03pm

RE: Test: Videopuffer im Treiber vergrößern

Quoted

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