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.

Dr. Seltsam

Im Forum Zuhause

Posts: 10,095

Location: 3. Planet des Sonnensystems

Occupation: Organisator

  • Send private message

41

Friday, June 17th 2005, 7:29pm

tja, so ist Cooper halt. Der Ton macht die Musik, und da fühlte er sich wohl leicht angep... ;)

Das Problem ist aber wirklich da, und wohl auch nicht ganz einfach zu lösen.

Die Treiber müssen nicht unbedingt schuld sein, obwohl die Umschaltzeit m.E. immer noch einen Tick schlechter ist als bei dem alten HEAD-Zweig für Kernel 2.4.

Vdr selbst ist auch betroffen: siehe
http://www.vdrportal.de/board/thread.php?threadid=33238
Das Statement von "TheAlamo" vom 26.04.2005 23:19 trifft den Punkt.

Ich sehe 3 Lösungen:
-Entweder schaffen es die DVB-Treiber-Entwickler, dass die Karte auch mit dvb-kernel schnell einen Lock bekommt (was beim alten Treiber der Fall ist)
-oder man nutzt eine speziell für DVB-T kompilierte Variante ohne die Prüfung, ob es einen Lock gibt

-oder man findet die Stelle in den vdr-sourcen, die die Wartezeit definiert und setzt diese etwas höher
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

oppee

Intermediate

Posts: 203

Location: Köln

Occupation: Student

  • Send private message

42

Friday, June 17th 2005, 8:14pm

Also so wie ich das verstehe, geht das ganze weit über Linvdr hinaus und betrifft ausschließlich DVB-t Karten bzw. deren Treiber? Muss gestehen daß ich hier relativ selten mitlese, wenn ich nicht gerad ein Problem an der Kiste habe. Schon gar nicht in den Unterforen der anderen Distributionen.
Na ja, wenn es also schon einmal besser war mit den älteren Treibern, und mit der zunehmenden Verbreitung von DVB-t besteht ja vielleicht Hoffnung, irgendwann einmal den gleichen Komfort wie auf den C und S Karten zu haben. *träum*

Gruß
Oppee

43

Saturday, June 18th 2005, 10:05pm

gelöst

Hallo,

für mich als reinen DVB-T Nutzer ist das Problem gelöst. Der Hinweis von Dr. Seltsam hat für mich die Lösung gebracht. Vielen vielen Dank!!!

Ich lasse den vdr nicht mehr auf ein Lock der Karte warten:
in device.c der vdr-sourcen habe ich die Funktion
bool cDevice::AttachReceiver(cReceiver *Receiver)
so angepasst, dass nicht mehr auf ein Lock gewartet wird.

Vorgehen:
- Kernel Sourcen der DarkAngel Version installiert
- Sourcen meines aktuellen MT-Patches installiert
- Compiler, make, etc., wie auf LinVDR.org beschrieben installiert
- ein paar symlinks gesetzt
- device.c angepasst
- vdr neu kompiliert und installiert
-> Problem weg, juhu!!

Bleibt nur zu hoffen, das es bald einen (darkangel) 2.6.12 Kernel gibt, in diesem hat sich, wie ich gesehen habe, auch etwas an den relevanten DVB Treibern geändert. Vielleicht geht ja mit diesen der Tune-Vorgang der DVB-T Karten schneller.

Ich bin sehr froh, dass ich bei LinVDR bleiben kann, tolle Distro! Auf tieferes Einsteigen hatte ich auch gar keine Lust, in meiner Freizeit will ich bei Bedarf mal gerne Fernsehen, aber nicht auch noch rumhacken...

Nochmals vielen Dank für die Hilfe!

Gruß
acid
athlon xp 2500+ :: asus a7n8x-x :: 512MB RAM :: Maxtor 250 GB HD :: Silverstone LC03 :: TT DVB-S 1.6 FF :: 2x TT DVB-T 1300 budget :: linvdr 0.7 :: linvdr-0.7-mt-1.3.23-20050403 :: One for all URC-7030

Dr. Seltsam

Im Forum Zuhause

Posts: 10,095

Location: 3. Planet des Sonnensystems

Occupation: Organisator

  • Send private message

44

Sunday, June 19th 2005, 12:13am

RE: gelöst

prima! vielleicht kannst Du die neue vdr-datei ja irgendwo zum Download bereitstellen? Gibt bestimmt noch mehr, die das interessiert.

Gibt`s eigentlich beim Umschalten ein Stotter-Problem? Wenn man sowieso ein spezielles vdr-binary für DVB-T benutzt, könnte man evtl. auch den Buffer allgemein etwas erhöhen (wie es für das Analogtv-Plugin gemacht wird).
siehe http://www.vdr-portal.de/board/thread.php?threadid=34249
1024k ist m.E. aber zuviel. Vielleicht mal 576 nehmen.

Beim MT-Patch vom 18.5. fehlt der Patch für analogtv übrigens, die Sourcen sind zumindest in dieser Hinsicht noch plain-vanilla.
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

Dr. Seltsam

Im Forum Zuhause

Posts: 10,095

Location: 3. Planet des Sonnensystems

Occupation: Organisator

  • Send private message

45

Sunday, June 19th 2005, 12:31am

Quoted

Original von Dr. Seltsam

-oder man findet die Stelle in den vdr-sourcen, die die Wartezeit definiert und setzt diese etwas höher


o.k., das ist in device.c

Source code

1
#define TUNER_LOCK_TIMEOUT 5000 // ms


Das heißt, die Umschaltdauer muss 5 Sekunden übersteigen, damit das Problem auftritt? Na ja, in den einschlägigen Testberichten von DVB-T-Karten hat die beste Karte 3 Sekunden Umschaltzeit bei unterschiedlichen Transpondern. Die schlechtesten liegen bei 5 und 6 Sekunden, das kann dann wirklich schon eng werden. Das sind Umschaltzeiten bei Windows-Treibern, aber anscheinend sind die aktuellen Linux-Treiber aus dem CVS nicht besser. Dass es bei DVB-T nicht so flott wie bei C oder S geht, ist ja bekannt.
Man könnte also auch den obigen Wert einfach auf 10000 erhöhen, wenn man auf die Lock-Prüfung in gemischten Systemen nicht verzichten will.

Aber 10 Sekunden Umschaltzeit? Mann, das ist heftig...
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

Sunday, June 19th 2005, 1:54am

Irgendie widerstrebt mir es, ein binary ohne sourcen, GPL Licence, etc. zum download anzubieten. Wer das Binary des vdr für linvdr-0.7-mt-1.3.23-20050414 will, kann mich ja kontaktieren. Eine saubere Lösung wäre das ganze über /etc/vdr/setup.conf zu steuern:
a la:
device.wait_for_lock=<0|1>
device.wait_for_lock_timeout=<xxx ms>

Ich sehe mir morgen nochmal device.c etc. an, ob man das ganze noch ahängig von der Art des device (nur DVB-T) steuern kann...

Ich muss sagen, ich bin absuluter Neuling mir Linux basiertem Fernsehen, seit ich anfang Juni zwangsweise von analog auf DVB-T wechseln mußte. Das Forum hier ist echt super, nur die Suchfunktion könnte besser sein. Man will ja nicht mit Standard-Problemen rumnerven...
So ein "Patch" für DVB-T könnte ja in die MT-Patches mit einfließen, wie ist da der offizielle Weg?

Gruß
acid

P.S.: "Der aktuelle DVB-Treiber aus dem CVS" damit meinst Du den von Linuxtv.org? So wie ich das verstehe, haben inzwischen die DVB-Treiber Einzug in den aktuellen Kerneltree gehalten, und sind dort am aktuellsten (siehe Kernel 2.6.12). Bitte korrigiere mich, falls ich hier falsch liege.
Stotterprobleme hatte ich bisher nicht. Die Tune-Dauer variiert bei mir stark, bis zu ca. 10 Sekunden beim Bouquet-Wechsel, meistens geht es aber viel schneller.
athlon xp 2500+ :: asus a7n8x-x :: 512MB RAM :: Maxtor 250 GB HD :: Silverstone LC03 :: TT DVB-S 1.6 FF :: 2x TT DVB-T 1300 budget :: linvdr 0.7 :: linvdr-0.7-mt-1.3.23-20050403 :: One for all URC-7030

This post has been edited 2 times, last edit by "acidbabe" (Jun 19th 2005, 2:03am)


Dr. Seltsam

Im Forum Zuhause

Posts: 10,095

Location: 3. Planet des Sonnensystems

Occupation: Organisator

  • Send private message

47

Sunday, June 19th 2005, 9:26am

Quoted

Original von acidbabe

So ein "Patch" für DVB-T könnte ja in die MT-Patches mit einfließen, wie ist da der offizielle Weg?


MT fragen :)
Aber er hat ja schon erklärt, dass es mangels Zeit erstmal keine neuen Patches mehr geben wird. Falls man die Lock-Prüffunktion selektiv (nur für DVB-T) abschalten/verändern könnte, wäre das ideal. Oder per Menü. Ansonsten hätte man das Problem, dass die C oder S-Nutzer vielleicht wieder Probleme (UPT etc.) kriegen.

Quoted


P.S.: "Der aktuelle DVB-Treiber aus dem CVS" damit meinst Du den von Linuxtv.org? So wie ich das verstehe, haben inzwischen die DVB-Treiber Einzug in den aktuellen Kerneltree gehalten, und sind dort am aktuellsten (siehe Kernel 2.6.12). Bitte korrigiere mich, falls ich hier falsch liege.


Die Entwickler basteln fast täglich an den Treibern rum, so dass man über das CVS von Linuxtv.org immer den neuesten Stand hat. Wobei neu nicht immer besser sein muss.... das große Problem ist, dass seit Monaten (Jahren?) keine stabilen Zwischenversionen veröffentlicht werden. Die Treiber sind in Dauer-Entwicklung. Irgendwann geht dann ein Entwicklungsstand an die "Kernelwächter", der dann bei Veröffentlichung des Kernels natürlich auch schon nicht mehr der neueste ist.

Ende Mai gab es mal eine Diskussion auf der linux-tv-mailing list, weil ein user lange Lock-Zeiten hatte.

"...besides i detected that the card locks faster with QAM_64 modulation as with QAM_16 modulation, though the dvb-t provider says it is using QAM_16 modulation."
der Entwickler schrieb dann "For me this sounds like i didn't mess things up with my changes but the initialization procedure for the tda10045 wasn't perfect in older versions either and the driver should be optimized a bit. Unfortunately i can't do this since i don't have any hardware to test the tda10045 specific code.
Can anybody else do this?"

Da weiter keiner antwortete, war das Thema damit beendet... Ist natürlich auch sehr unglücklich, wenn ohne praktische Prüfmöglichkeit nur auf theoretischer Basis an den Treibern gearbeitet wird. Ich hätte an seiner Stelle Lorenzen um ein Exemplar gebeten. Es müsste doch auch in deren Interesse liegen, dass es funktionierende Linux-Treiber gibt.


Quoted


Stotterprobleme hatte ich bisher nicht. Die Tune-Dauer variiert bei mir stark, bis zu ca. 10 Sekunden beim Bouquet-Wechsel, meistens geht es aber viel schneller.


schau bitte nochmal mit femon, ob es wirklich so lange bis zum Lock dauert. Dass das Bild später kommt, kann auch am AC3-Buffer liegen. Der muss erst gefüllt sein, das macht bestimmt auch noch mal 1-2 Sekunden.
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

oppee

Intermediate

Posts: 203

Location: Köln

Occupation: Student

  • Send private message

48

Monday, July 25th 2005, 4:01pm

Hi,

mit dem Darkangel Kernel 2.6.12.2 und der neuen Firmware fw-dvb

unter http://www.vdrportal.de/board/thread.php?threadid=35897&sid=

gehts jetzt. Keine Lock-Probleme mehr und Umschaltzeiten beim Transponderwechsel von 2 Sekunden. Freu mich tierisch daß Linvdr0.7 jetzt auch uneingeschränkt DVB-t fähig ist.

Siehe auch http://www.vdrportal.de/board/thread.php?threadid=35691&sid=

Vielleicht kann der Thread-Ersteller es ja mit in den Titel (Lösung) packen.
Gruß
Oppee

Dr. Seltsam

Im Forum Zuhause

Posts: 10,095

Location: 3. Planet des Sonnensystems

Occupation: Organisator

  • Send private message

49

Monday, July 25th 2005, 6:56pm

das sind ja gute Nachrichten. Ich frage mich nur, was da nun den Unterschied bewirkt hat.

Zuletzt hatte hier jemand berichtet, dass es mit DarkAngels Kernel 2.6.12.1 auch nicht richtig läuft.

Im CVS ist am 13.6. folgende Änderung beim tda1004x verzeichnet:

Quoted

- added preliminary support for tda827x tuners
- set parameters for drift compensation to 0
makes no sense for DVB-T but can prevent lock

Ich glaube mich zu erinnern, dass DarkAngel diesen CVS-Stand in seinem 2.6.12.1 vom 30.6. schon drin hatte.

An der Firmware ist seit Monaten nichts geändert worden.
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

oppee

Intermediate

Posts: 203

Location: Köln

Occupation: Student

  • Send private message

50

Monday, July 25th 2005, 7:12pm

Zu dem 2.6.12.1 kann ich nix sagen, da ich mich erst heute wieder an das Problem begeben habe, und diesen also übersprungen hab.

Gruß
Oppee

Dr. Seltsam

Im Forum Zuhause

Posts: 10,095

Location: 3. Planet des Sonnensystems

Occupation: Organisator

  • Send private message

51

Monday, July 25th 2005, 11:59pm

ich habe mir jetzt mal das Modul tda1004x mit den Soucren aus dem CVS für Kernel 2.6.9 compiliert.
Tatsächlich scheint das Tunen jetzt fix zu gehen!

Ich habe nur ein Problem:

Beim Booten hängt es jetzt 10 Sekunden:

Jul 25 23:23:36 linvdr user.info kernel: tda1004x: found firmware revision 0 -- invalid
Jul 25 23:23:36 linvdr user.info kernel: tda1004x: waiting for firmware upload (dvb-fe-tda10045.fw)...
Jul 25 23:23:46 linvdr user.err kernel: tda1004x: no firmware upload (timeout or file not found?)
Jul 25 23:23:46 linvdr user.warn kernel: tda1004x: firmware upload failed

danach geht es weiter, und es kommt auch ein Bild. Also wohl eine spontane Selbstheilung :-)
nee, im Ernst, die aktuelle Firmware liegt natürlich in /usr/lib/hotplug/firmware wie immer.

Ich finde beim googlen jede Menge Threads dazu auf der mailinglist. Angeblich soll es im CVS gefixt sein, aber es gibt auch Leute die das nicht bestätigen.

Schaue doch bitte mal in Dein Log, ob Du da auch sowas siehst.
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

oppee

Intermediate

Posts: 203

Location: Köln

Occupation: Student

  • Send private message

52

Tuesday, July 26th 2005, 1:27am

Hi,
bei mir scheint das nicht aufzutreten:

Jul 26 01:13:33 linvdr user.debug vdr[2828]: probing /dev/dvb/adapter0/frontend0
Jul 26 01:13:33 linvdr user.debug vdr[2841]: tuner on device 1 thread started (pid=2841, tid=1026)
Jul 26 01:13:33 linvdr user.debug vdr[2842]: Section handler thread started (pid=2842, tid=2051)
Jul 26 01:13:33 linvdr user.debug vdr[2828]: probing /dev/dvb/adapter1/frontend0
Jul 26 01:13:34 linvdr user.info kernel: tda1004x: found firmware revision 0 -- invalid
Jul 26 01:13:34 linvdr user.info kernel: tda1004x: waiting for firmware upload (dvb-fe-tda10045.fw)...
Jul 26 01:13:35 linvdr user.info kernel: tda1004x: firmware upload complete
Jul 26 01:13:35 linvdr user.info kernel: tda1004x: found firmware revision 2c -- ok
Jul 26 01:13:35 linvdr user.debug vdr[2861]: tuner on device 2 thread started (pid=2861, tid=3076)
Jul 26 01:13:35 linvdr user.debug vdr[2862]: Section handler thread started (pid=2862, tid=4101)
Jul 26 01:13:35 linvdr user.debug vdr[2828]: probing /dev/dvb/adapter2/frontend0
Jul 26 01:13:35 linvdr user.info vdr[2828]: found 2 video devices
.
.
Jul 26 01:13:35 linvdr user.info vdr[2828]: setting primary device to 1

Hoffe es hilft dir.

Gruß
Oppee

MR42HH

Intermediate

Posts: 438

Location: Schleswig-Holstein

Occupation: Ingenieur Verfahrenstechnik

  • Send private message

53

Tuesday, July 26th 2005, 7:08am

kein Bild direkt nach Transponderwechsel

Moin, ich habe ein ganz ähnliches Problem. Auf meinem DVB-T System habe ich direkt nach einem Transponderwechsel zunächst kein Bild. Wechsle ich auf einen anderen Kanal des selben Transponders, is das Bild dann da.
Ich nutze LinVDR mit dem Originalkernel - bringt vielleicht ein neuerer Kernel Besserung?

Gruß,

m.

mein VDR:
Siemens Gigaset 740AV, Buffalo Linkstation NAS
in meiner Bastelkiste:
2x Activy 300, 1x MediaPortal mit GLCD, 1x Fujitsu-Siemens Jetson, 1xDVB-C Rev.2.1, Airstar2, neue Nova-T, Linksys NSLU2, defekte 2300C

Dr. Seltsam

Im Forum Zuhause

Posts: 10,095

Location: 3. Planet des Sonnensystems

Occupation: Organisator

  • Send private message

54

Tuesday, July 26th 2005, 8:36am

Quoted

Original von Dr. Seltsam
Jul 25 23:23:46 linvdr user.warn kernel: tda1004x: firmware upload failed



ich habe gerade einen Geistesblitz!
Da ich vorher meinen selbstgebastelten Kernel 2.4.31 laufen hatte, war sysfs nicht gemountet (hatte ich in /etc/fstab auskommentiert). Wahrscheinlich läuft hotplug dann nicht korrekt. Werde es also heute abend nochmal mit gemountetem sysfs testen.
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

oppee

Intermediate

Posts: 203

Location: Köln

Occupation: Student

  • Send private message

55

Tuesday, July 26th 2005, 11:23am

@MR42HH

Schau dir logread nach einem fehlgeschlagenen Kanalwechsel an.
Wenn da was von "Device ... has no lock" steht, dann sollte es der gleiche Fehler sein. Und wenn deine Umschaltzeiten auch dermaßen schlecht sind wie es meine waren, dann würd ich nicht zögern, es auszuprobierren.

Gruß
Oppee

MR42HH

Intermediate

Posts: 438

Location: Schleswig-Holstein

Occupation: Ingenieur Verfahrenstechnik

  • Send private message

56

Tuesday, July 26th 2005, 8:15pm

Quoted

Original von oppee
Und wenn deine Umschaltzeiten auch dermaßen schlecht sind wie es meine waren, dann würd ich nicht zögern, es auszuprobierren.


Meine Umschaltzeiten waren ganz OK - ich hab's trotzdem mal riskiert. Resultat: Zappen geht jetzt auch querfeldein problemlos. Schönen Dank!

Gruß,
Mirko

mein VDR:
Siemens Gigaset 740AV, Buffalo Linkstation NAS
in meiner Bastelkiste:
2x Activy 300, 1x MediaPortal mit GLCD, 1x Fujitsu-Siemens Jetson, 1xDVB-C Rev.2.1, Airstar2, neue Nova-T, Linksys NSLU2, defekte 2300C

Immortal Romance Spielautomat