welche debug_mask ist das Minimum um zu sehen wann mcli was von einem Tuner will ?
Ich würde sagen, alle DEBUG_BIT_TUNE_* von hier- das wäre 0x46.
Zu den Tunern: beim VDR sind Tuner nie inaktiv, wenn ein Device einmal verwendet wurde, bleibt auch das tunng. Wenn du dem VDR 3 Devices erlaubst, werden irgendwann auch 3 Tuner aktiv sein. Im Netceiver müssen das aber nicht immer die Gleichen sein, da er nach Bedarf aus den vorhandenen 6 Tunern auswählt.
LG Helmut
Das tut es bei mir auch:
Nur 1 Device auf Kanal 7, dann umschalten auf 5, 6 und 7 mit Http-Priority 0.
Bei jeder wget Anforderung wird das Bild schwarz mit der Meldung "Streaming active", das kommt das Livebild auf dem neuen Sender - mit der OSD-Meldung "Kanal nicht verfügbar". Nachdem die Anzeige des OSD ausgeblendet wird, ist der neue Sender bis zum nächsten wget ganz normal zu sehen.
Das "Kanal nicht verfügbar"kommt daher, weil der streamdev-server kein Switchchannel() ausführt, sondern die Receiver des Device einfach abklemmt. VDR bemerkt, dass es kein aktives Programm mehr gibt und will wieder auf das letzte ihm bekannten Programm umschalten (sogar 2 mal). Das geht aber nicht weil es entweder auf einem anderen Transponder ist oder weil die Priority des Device von Streamdev-server zu hoch ist.
Das ist vielleicht nicht schon anzusehen, aber ganz normales verhalten. Hier das Syslog auf dem Server. Die "switching to channel.." Meldungen kommen vom VDR.
LG Helmut
pbrb : Zwei DEBUG_TUNE_PC Meldungen sollten dann auch noch angepasst werden.
LG Helmut
Ich habe es jetzt so getestet: 2 Devices, Auf Device 1 läuft eine Aufnahme auf Kanal 5, Device 3 iäuft mit IDLEPRIORITY (-100).
Streamdev-server Http-Priority ist 0. Dann wird mit wget alle 10s auf die Kanäle 5, 6 und 7 umgeschalten.
Im Syslog des Server - mit einer debug-Ausgabe in GetDevice()
Soweit alles wie zu erwarten. Wichtig ist meiner Meinung nach, dass das timeout für das Einlesen der EPG-Daten mindestens 15s bis 20s sein sollte. Bei nur 1s wird ziemlich sicher der Transponder zu schnell weggeschalten.
LG Helmut
Der fix-handling-IDLEPRIORITY Commit für vdr-1.7.27 sollte besser auch noch dabei sein.
LG helmut
Möglicherweise liegt es an diesem Commit für vdr-1.7.25: Revised priority handling.
Der Patch für mcli:
Im Anhang vdr-plugin-mcli-0.9.6_p01 mit diesem Patch.
LG Helmut
Es werden schon alle Bereiche geprüft auf die memtest Zugriff hat - 0x40000000-0x7fffffff sind 1GiB, die oberen 256 MiB davon sind für cma reserviert. Es sieht aber fehlerfrei aus. Einen ausführlicheren Test macht vielleicht memtest86, direkt vom USB-Stick gestartet.
Es wäre natürlich gut wenn es nicht am RAM liegt, aber mehr fällt mir dazu im Augenblick auch nicht ein. Der VDR läuft normalerweise auch auf 64-Bit problemlos.
LG Helmut
Ob es nicht doch ein Speicherproblem ist? Es sieht mehr danach aus, als ob im RAM ein oder mehrere Bits umfallen und dann mit ungültigen Pointern gearbeitet wird. Dass es meistens in eit.c/epg.c passiert liegt vielleicht daran, das hier mehr RAM benötigt wird und man so in einen fehlerhaften Bereich kommt.
Starte doch einmal mit den Kernel Parameter memtest=1 (siehe auch: automatically-memtest-and-then-boot )
LG helmut
Das eine unveränderte Config nicht immer neu geschrieben werden muß, hab ich mir auch schon öfter gedacht. Im Anhang nun ein Patch dazu.
Aber das "verflüchtigen" klingt irgendwie geheimnisvoll.
Helmut
In vdr.c wird der Timercheck auch auf Patterntimers angewendet. Das führt bei zeitlicher Übereinstimmung dazu, dass alle 10 Sekunden versucht wird ein Device für die vermeindlich anstehende Aufnahme umzuschalten. Bei einem Pattern für z.B. 00:00 bis 23:59 Uhr wäre das dann 24 Stunden lang. Hier ein Patch der das vermeidet:
Helmut
Wo könnte ich suchen ?
Du musst nichts suchen, nur warten.
Der VDR scannt das EPG sortiert nach Transponder (Frequenz) und nicht nach Kanalnummer. Je nach Inhalt deiner channels.conf und UpdateChannels Einstelung können es auf Astra 19.2E bis zu 120 Transponder sein. Es werden immer 20 Sekunden lang die EPG Daten eingelesen - sieht man auch in deinem Log:
Mit nur einem freien Device dauert es daher bis zu 40 Minuten um alle Transponder einmal durchzuschalten.
Bei einem Tastendruck auf der FB wird der Scan Vogang unterbrochen - oder abgebrochen wenn das EPG-Update nur manuel erfolgt.
LG Helmut
Ich habs mir angesehen.
0318b ist so wie zu erwarten - nach 30s wird das Datum ans CAM gesendet, dann hört die Enschlüsslung auf und durch die ScrambleDetection wird ein Retune veranlasst. Also alles ganz "normal" und (fast) unter Kontrolle.
In 0318a sieht im Netceiver alles normal aus und die Entschlüsslung sollte beginnen. Möglicherweise dauerte es aber immer etwas zu lange bis die ECMs empfangen wurden und die ScrambleDetection reagiert nach 3 sec mit CAM0: wan't decrypt channel...
Lass den VDR etwas länger auf die Entschlüsselung warten - z.B 5 Sekunden mit --scrtmo=5.
assuming manual start of VDRist nicht neu. Zum Setzten des inactivity-Timers versucht VDR festzustellen, ob es ein manueller Start oder ein Wakeup-Start für eine Timeraufnahme war. Bei Timeraufnahmen beended sich der VDR gleich nach der Aufnahme wieder, sonst erst nach der Inactivity-Zeit wie sie im Setup eingestellt ist - z.B. nach 2 Stunden ohne User Eingriff. Alsmanual start gilt, wenn in den nächsten 10 Minuten keine Aufnahme ansteht.
LG Helmut
ar 16 19:39:59 BM2LTS-N64native-MCLI rc.local[1595]: Error resolving ntp.ubuntu.com: System error (-11)
Kann auch nicht gehen:
Wieso fehlt das: /usr/sbin/dhcpcd: No such file or directory?
Da stimmt irgendetwas mt deiner Installation nicht. Du hast ja sehr häufig Fehler wegen fehlender Verzeichnisse, shared Libraries oder Zugriffsrechten. Möglicherweise gibt aber auch deine hdd den Geist auf.
LG Helmut
- war da nicht noch x8000 zum Anwählen des 1. Kanals in der channels (wozu auch immer das jemals gut war) ?
- bringt aus deiner Sicht das CA=11 eig. etwas ?
0x8000 war nur der Versuch, die Pid 0 für das CAM-Triggern zu verwenden. Das ging aber nicht und wurde daher wieder enfernt.
CA 11 (=0x11) oder 12 (=0x12) ist meiner Meinung nur erforderlch, wenn beide CI-Slots verwendet werden und einzelne Programme dem richtigen Slot zugeordnet werden sollen. Mit nur einem Modul gibt es ja keine große Auswahl, daher wird es auch nichts bringen.
LG Helmut
Beim Durchlesen deines vorletzten Commit auf github ist mir aufgefallen, das es durch die TriggerCam-Option ohne eingestecktem Modul und ohne --cam-disable in SetChannelDevice() immer Fehermeldungen geben müsste. Stimmt das, ode ist es nur ein Trugschluß von mir?
Im Anhang auf jedefall ein Patch für dein mcli-0.9.6_pre5 mit einigen kleineren Anpassungen dazu.
Deinen cam-disable Commit habe ich auch etwas vereinfacht, indem ich gleich in ProcessArgs() das DEBUG_BIT_Action_SkipTriggerCam Bit in m_debugmask entsprechend setzte. Damit entfallen später ein paar Überprüfungen.
LG helmut
In der Version 0.9.6pre4 von pbiering sind alle schlußendlich relevanten Patches und fixes bereits enthalten.
Das sind.
- TriggerCAM gleich nach dem Power-on auch wenn der Startkanal FTA ist um das richtige Datum so schnell wie möglich an das CA-Modul zu übergeben
- DeviceReadyWithCI - damit der VDR erst nach einem abgeschlossenem CAM-Reset auf den Startkanal schaltet
- SkipRetuneOnFirstTuner - damit das mcli-Plugin nicht von sich aus auf Kanal #1 schaltet, da bei einem verschlüsseltetn Kanal hier das CAM noch nicht bereit ist
- NOTIFY_CAM_CHANGE ist deaktiviert, da es sonst zu einer Überlagerungen mit dem Programm-OSD kommt
Das ist auch alles als default eingestellt, man muss keine Optionen in der debugmask mitgeben - außer man will das Verhalten umkehren
Das das mcli-Plugin immer die automatisch Pid 0 aktiviert stört offensichtlich nicht und wurde belassen.
Der vdr-2.4.6.mcli5.patch ist eigentlich nur erforderlich, wenn man mit dem Netceiver auch verschlüsselte Programme sehen will. Ohne CAM muß der VDR nicht gepatcht werden.
LG Helmut
Schön, dass das Retune jetzt wieder funktioniert. Mit deinen Plugins bzw. deren Reihenfolge kann ich dir leider nicht helfen - einfach ausprobieren ob es eine besondere Reihenfolge braucht.
Ich brauche keine weiteren Tests, du kannst natürlich zum deinem Ausgangsproblem zurück und eine verschlüsselte Timeraufnahme testen.
Die Bildstörungen bzw. das Retune treten ja nur bei verschlüsselten Programmen und irgendwann in den ersten 60 sec. nach dem Power-On auf, Timeraufnahmen die danach beginnen sind daher nicht mehr betroffen.
Deine "Alltags" debug_mask ist ja inzwischen schon "Hart" einprogrammiert - TS_SCRAMBLING_TIME_OK mit 60s im vdr-mcli5 und TRIGGER_CAM mit 0x4000 im mcli-0.9.5n Plugin (das sich aber noch als "m" meldet). Mehr brauchst du nicht. Das Loggen mit 0xdf kannst du auch weglassen.
LG Helmut
Es gibt ein Update mit der Version 0.3.4_pre3 auf github.
Neu sind die 2 Modulparameter force_versionund force_vendor und um die Firmware und Hardware selbst auszuwählen:
force_vendor, " Force hardware vendor (0: Auto, 1: Hauppauge 2: SmartDTV+TerraTec, default:0)."
force_version, " Force firmware version (0: Auto, 1..4: Version, default:0)."
jsffm : Die unnötigen "..not SYNC.." Meldungen sollten jetzt bei dir auch nicht mehr aufscheinen - hoffe ich zumindest. Ich kann es selbst nicht so gut nachstellen.
LG helmut
Im 'vdr-2.4.6.mcli4.patch' habe ich durch eine kleine Änderung die scrambleDetection unbrauchbar gemacht.
Hier der 'vdr-2.4.6.mcli5.patch' bei dem das wieder richtiggestellt ist. Gleichzeitig habe ich die TS_SCRAMBLING_TIME_OK nun auf 60 sec. eingestellt.
Das mcli-Plugin ist unverändert die Version 0.9.5n, im Anhang aber eine Binary gegen den Vdr mit dem mcli5.patch.
gggggg : Bei deinen 3 Logs von heute Vormittag war wieder MULTI_SID eingestellt. Das funktioniert zumindest auf dem NUC nicht brauchbar, da damit das CAM genau einem Device zugeordnet wird. Ein Ändern der Zuordnung auf ein anderes Device (z.B. bei Transponderwechsel ORF2 -> ORF1) geht mit dem vorhandenen Code vielleicht bei FullFeatured Devices, aber nicht im Transfermode wie beim NUC - warum auch immer.
Mar 13 10:50:21 BM2LTS-N64native-MCLI vdr: [1085] Mcli::SetChannelDevice: failed to get CAM on DVB 3 (cam_force=false)
Also im Netceiver immer MULTI_TRANSPONDER einstellen.
LG Helmut
