Posts by te36

Hatteen wir oben schon. Wenn was haengt scheint das nur ein thread zu sein.

Habe extra gentoo ohne systemd. Steht also alles in den logfiles drin ohne das ich mich mit systemd rumschlagen muss.

Die Frage hier war ja in erster Linie was fuer Gruende VDR selbst haben koennte, so das es den log fuer "timer.. started" nicht bringt. Die Hoffnung das man den Grund aus irgend etwas anderem, was im System passiert ist, schliessen kann hatte ich ja auch - aber habe im Log halt nix gefunden.

Ich hatte noch gedacht, das ja die Aufnahme nicht gestarted wurde wegen VPS, aber der Autotimer, der den Teimer erzeugt hat kein VPS programmiert.

Evtl. hat der Tuner Schwierigkeiten gehabt, aber da haette ich dann auch auf vdr Fehlermeldungen gehofft.

Ich werde halt mal ueberlegen was ich noch an zusaetzlicher Diagnostik reinkonfigurieren kann. Loglevel erhoehen, regelmeassig mit SVDRP/LSTT die timer ziehen, etc. pp. *seufz*.

Quote from nobanzai

das sieht nach --unit=vdr aus.

was soll das bedeuten ?

?

Wie gesagt, da ist nix aufklaerendes drin IMHO:

Jun 12 12:25:00 server vdr: [20326] SVDRP server < 192.168.5.7:48486 client connection accepted
Jun 12 12:25:00 server vdr: [20326] SVDRP server < 192.168.5.7:48486 connection closed
Jun 12 12:25:00 server vdr: [20326] SVDRP server < 192.168.5.7:48502 client connection accepted
Jun 12 12:25:00 server vdr: [20326] SVDRP server < 192.168.5.7:48502 connection closed
Jun 12 12:29:18 server vdr: [20316] Streamdev: Setting data connection to 192.168.5.10:33341
Jun 12 12:29:31 server vdr: [20326] SVDRP server < 192.168.5.7:48316 client connection accepted
Jun 12 12:29:32 server vdr: [20326] SVDRP server < 192.168.5.7:48316 connection closed
Jun 12 12:29:34 server vdr: [20326] SVDRP server < 192.168.5.7:48330 client connection accepted
Jun 12 12:29:34 server vdr: [20326] SVDRP server < 192.168.5.7:48330 connection closed
Jun 12 12:29:37 server vdr: [20326] SVDRP server < 192.168.5.7:48346 client connection accepted
Jun 12 12:29:37 server vdr: [20326] SVDRP server < 192.168.5.7:48346 connection closed
Jun 12 12:29:38 server vdr: [20326] SVDRP server < 192.168.5.7:48362 client connection accepted
Jun 12 12:29:38 server vdr: [20326] SVDRP server < 192.168.5.7:48362 connection closed

...

Ja, das war ja am naechsten Tag, da hatte ich den VDR neu gestartet, und da hat er dann den timer geloescht. Aber zur Zeit der Aufname waren wirklich keine anderen interessanten logs zu sehen. Immer wieder mal eine SVDRP Anfrage, oder streamdev anfrage von einem client. Nix das mir erklaeren wuerde, warum VDR sich nicht um den Timer kuemmert.

Das vdrrecord-gate.sh ist glaube ich der script um sowas wie werbung automaisch rausschneiden aufzurufen. Bei mir macht das aber nix.

Die Aufnahmen sind alle bloss auf dem Server programmiert.

Ich glaube wenn das live plugin nicht will wird nix geloggt *sigh*

Ich sag ja, kein hilfreiches logging.

Die rasperry's greifen per streamdev auf den server zu. Der SatIP server ist ja separate Kiste von Digital Devices (Octonet Pro). Der hat 8 tuner. Das reicht immer locker.

Die Kiste ist auch Server mit 10 HDD, und da hatte ich vor kurzem mal riesige Umkopieraktion gemacht. Wenn da irgend was mit Netzteil nicht in Ordnung waere, dann waere das dort zuerst aufgeflogen.

Beim Einbau des neuen LNB hat der Fernsehtechniker bis zum PC/SATIP durchgemessen. Sieht alles super aus.

Frueher mit der Cine-S2 PCIe Karte kamen halt immer mal wieder zu viele Aussetzer. Das ist seit Umstellung auf SATIP und neuem LNB weg. Kann also LNB und/oder PCIe Bus Problem gewesen sein.

Ich versuche ja eher zu verstehen, wie das sein kann, das der VDR eine Aufnahme in seiner Liste hat, die er dann nicht startet. Aber natuerlich kann ich das jetzt so mit dem Log wie er ist nicht beweisen. Da muss ich mir ja wohl erst mal einen Script schreiben der regelmaessig mit LSTT abreift was der VDR fuer programmierte Aufnahmen hat, und dann Fehler meldet, wenn fuer eine Aufnahme keine "start" Logmeldung da ist.

Und wie gesagt, der VDR ist wenn das passiert auch irgendwie verklemmt. Muss ich wohl auch mal per SVDRP gucken, was dann noch geht.

Hatte gehofft, das die Fehlersituation irgendwo eine Klingel ausloest "das kenne ich" oder so.

Noe, platte ist nicht voll.

DIe Installation vor dem Upgrade war mindestens 8 Jahre alt und lief nur wirklich mit SD stabil. Also dann Ende letzten Jahres alles neu gemacht und nur noch rechtlich-oeffentlich HD in den channel.conf drin. Gentoo neu aufgesetzt (4'er auf 6'er Kernel). Aber immer noch Aussetzer in den Aufzeichnungen, Cine-S2 im Verdacht, ersetzt durch SAT-IP, erst EXIP 418, Aber da auch kaputte Aufnahmen, dann LNB ausgetauscht, aber da hat er immer noch videosignal nach einiger Zeit verloren, dann jetzt Octonet Pro server. Und so lang/stabil wie jetzt war es vorher nicht. Aber eben immer noch die immer mal fehlenden Aufnamen - und VDR der dann gar nicht mehr ueber OSD diagnostiziert werden kann.

Also mit "was hat sich geaendert" komme ich nicht weiter ... *sigh*

VDR 2.6.9 auf aktuellem Gentoo. Laeuft nur als Server ohne Ausgabekarte mit RPI/VDR clients im Netz. Nach dem letzten Upgrade von hmm... 2.2.1 oder so:

Immer nach ein paar Tagen scheint VDR keine neuen Aufnahmen mehr zu taetigen. Und wenn ich danach nachschaue scheint der VDR auch insgesamt etwas verklemmt zu sein. Die Clients kriegen weiter ihre Streams, aber wenn ich ueber das live plugin auf die OSD GUI gehen will, dann funktioniert die auch nicht mehr.

Anbei mal 2 logs. Am 11. ging die Aufname noch, am 12. Nicht mehr. Der Unterschied faengt damit an, das da gar kein "timer...start" mehr erscheint. Aber wie koennte ich jetzt weiter debuggen ?

Die Aufnamen sind uebrigens ohne VPS programmiert.

---

Jun 11 10:26:16 server vdr: [20326] SVDRP server < 192.168.123.129:59586 added timer 319 (3 1223-1320 'In aller Freundschaft (864)')
Jun 11 10:26:16 server vdr: [20263] timer 319 (3 1223-1320 'In aller Freundschaft (864)') set to event Mi. 11.06.2025 12:25-13:10 (VPS: 11.06. 12:25) 'In aller Freundschaft (864)'
Jun 11 12:23:00 server vdr: [20263] timer 319 (3 1223-1320 'In aller Freundschaft (864)') start
Jun 11 12:23:00 server vdr: [20263] executing '/usr/share/vdr/bin/vdrrecord-gate.sh before "/local/media/vdr/In_aller_Freundschaft_(864)/2025-06-11.12.23.3-0.rec"'
Jun 11 12:23:00 server vdr: [20263] record /local/media/vdr/In_aller_Freundschaft_(864)/2025-06-11.12.23.3-0.rec
Jun 11 12:23:00 server vdr: [24867] executing '/usr/share/vdr/bin/vdrrecord-gate.sh started "/local/media/vdr/In_aller_Freundschaft_(864)/2025-06-11.12.23.3-0.rec"'
Jun 11 12:27:39 server vdr: [20281] channel 13 (NDR FS MV HD) event Mi. 11.06.2025 12:25-13:10 (VPS: 11.06. 12:25) 'In aller Freundschaft (864)' status 0->2
Jun 11 12:27:39 server vdr: [20281] channel 3 (NDR FS NDS HD) event Mi. 11.06.2025 12:25-13:10 (VPS: 11.06. 12:25) 'In aller Freundschaft (864)' status 0->2
Jun 11 12:28:20 server vdr: [20281] channel 13 (NDR FS MV HD) event Mi. 11.06.2025 12:25-13:10 (VPS: 11.06. 12:25) 'In aller Freundschaft (864)' status 2->4
Jun 11 12:28:20 server vdr: [20281] channel 3 (NDR FS NDS HD) event Mi. 11.06.2025 12:25-13:10 (VPS: 11.06. 12:25) 'In aller Freundschaft (864)' status 2->4
Jun 11 13:11:02 server vdr: [20281] channel 13 (NDR FS MV HD) event Mi. 11.06.2025 12:25-13:10 (VPS: 11.06. 12:25) 'In aller Freundschaft (864)' status 4->1
Jun 11 13:11:02 server vdr: [20281] channel 3 (NDR FS NDS HD) event Mi. 11.06.2025 12:25-13:10 (VPS: 11.06. 12:25) 'In aller Freundschaft (864)' status 4->1
Jun 11 13:20:00 server vdr: [20263] timer 319 (3 1223-1320 'In aller Freundschaft (864)') finished with 0 errors
Jun 11 13:20:00 server vdr: [20263] timer 319 (3 1223-1320 'In aller Freundschaft (864)') stop
Jun 11 13:20:00 server vdr: [20263] executing '/usr/share/vdr/bin/vdrrecord-gate.sh after "/local/media/vdr/In_aller_Freundschaft_(864)/2025-06-11.12.23.3-0.rec"'
Jun 11 13:20:00 server vdr: [20263] timer 319 (3 1223-1320 'In aller Freundschaft (864)') set to no event
Jun 11 13:20:00 server vdr: [20263] deleting timer 319 (3 1223-1320 'In aller Freundschaft (864)')

Jun 8 11:21:46 server vdr: [20263] timer 25 (13 1224-1315 'In aller Freundschaft (865)~Sorgenvolle Tage') set to event Do. 12.06.2025 12:25-13:10 (VPS: 12.06. 12:25) 'In aller Freundschaft (865)'
Jun 12 11:03:02 server vdr: [20326] SVDRP server < 192.168.123.129:36882 added timer 338 (3 1223-1320 'In aller Freundschaft (865)')
Jun 13 16:10:27 server vdr: [30663] timer 1 (13 1224-1315 'In aller Freundschaft (865)~Sorgenvolle Tage') set to event Do. 12.06.2025 12:25-13:10 (VPS: 12.06. 12:25) 'In aller Freundschaft (865)'
Jun 13 16:10:27 server vdr: [30663] timer 1 (13 1224-1315 'In aller Freundschaft (865)~Sorgenvolle Tage') set to no event
Jun 13 16:10:27 server vdr: [30663] deleting timer 1 (13 1224-1315 'In aller Freundschaft (865)~Sorgenvolle Tage')
~

Hast Du ueberhaupt schon mal eine sinnvolle channels.conf ?

Und ein passendes disecq.conf ? Z.b.:

S19.2E 11700 V 9750 [E0 10 38 F0]
S19.2E 99999 V 10600 [E0 10 38 F1]
S19.2E 11700 H 9750 [E0 10 38 F2]
S19.2E 99999 H 10600 [E0 10 38 F3]

Joe_D Danke!

Kompliziert fand ich ja erst mal, das da zwischen DVBS und DVBS2 unterschieden wird. Ich haette irgndwie erwartet, das DVBS2 so'ne art Obermenge von DVB ist, man dann also nie mehr DVBS erwaehnen muss, wenn man DVBS2 angibt.

Klar, das DVBS2 vs. DVB-C Beispiel von Dir macht viel Sinn, das sollte man mal dokumentieren

Ich hatte uebrigens Probleme mit satip, als ich "-D DVBS2" konfiguriert hatte - da gingen auf einmal all die privaten/SD Sender (ASTRA 19.2) nicht mehr. Entfernt, Problem weg. Wenn ich jetzt in die vtuner Logs schaue:

May 25 01:57:38 [11349 satip_config.c:200] debug: DVBS freq: 11508 mod: qpsk pol: v sym: 22000 fec: 56
May 25 01:57:59 [11349 satip_config.c:221] debug: DVBS2 freq: 10773 mod: 8psk pol: h sym: 22000 fec: 34 roff: 0.20 pilot: on

Aka... verstehe ich das richtig, das einige Sender (SD ?) Protokoll DVB verwenden, und andere das protokoll DVBS2 ?

Abhaengig von der Modulation ? qpsk noch DVB, 8psk dann DVBS2 ?

Kompliziertes Zeugs Aber falls sich mal jemand aufrafft eine echte Doku zu schreiben , vielleicht ganz gut zu verstehen, das man dann wahrscheinlich kein "-D xxx" verwenden will, damit beide Protokolle funktionieren... ?!

Habe bei mir Unicable, damit ich alle 8 Tuner verwenden kann, also Setup nicht 100% gleich.

Beim satip Programm gibts ja Parameter:

-f frontend on satip receiver, number between 1 to N (defaults to let receiver decide

So geraten wuerde ich sagen, das Du 3 x satip startes, jeweils mit frontent nummer 1,2,4. Muesstest Du dann ja in der Web-GUI des exip418 sehen, das tuner 3 nicht verwendet wird.

Aber eigentlich soltest Du mal gucken, was da kaputt ist. Kann ja eigentlich nur was am Kabel oder Multiswitchausgang sein. Solltest Du ja Durch umstecken eingrenzen koennen.

Joe_D Hoffe, ich hab das nicht in irgendeinem Beitrag übersehen, aber mit welchem SAT-IP Receiver verwendest Du die vtuner-software ? Auch gerne dieselbe Frage an andere im Thread.

Ich frage, weil ich dievtuner/satip-Kombination mit dem EXIP 418 verwenden wollte, aber in der Kombination gibt es irgendwie das Problem das nach einiger Zeit immer gerne mal

ERROR: video data stream broken

kommt, woraufhin dann VDR auch restarted - und natürlich alle anderen gleichzeitigen Aufnahmen kaputt gehen. Oder auch:

frontend 4/0 is not receiving transponder 111052 for channel 10 (ARD alpha HD) - retuning

Was dann anscheinend dazu führt das VDR irgendwann mit dem dvb Device die Schnauze voll hat und es nicht mehr verwendet, wodurch dann immer weniger Tuner verwendet werden.

Auf jeden Fall hab ich mir jetzt erst mal eine 'Octopus NET SL SX2 Basic - 8 Tuner' gekauft, die ja im Vergleich zum Kathrein ein echtes Schnäppchen ist - ziemlich genau doppelt so teuer. Aber ok. einen guten Teil davon hake ich unter open source firmware ab, und den anderen jetzt damit das das anscheinend mit vtuner bisher problemloser geht (toi toi toi).

weiss nicht, ob das mit den SCH downlink frequenzen waehlen bei der Eingrenzung Deines Problems alleine so hilfreich ist, wenn es doch scheint, das es an einer der DVB-Karten liegen koennte.

Ich empfehle, den VDR mal so zu starten, das nur einer der beiden DVB Tuner verwendet wird, also -mit "-D 1" oder "-D 2". Und dann um auf Nummer sicher zu gehen, das man weiss um welche Hardware es sich handelt dann auch jeweils das Antennenkabel am anderen, nicht verwendeten Tuner abziehen. Und dann halt kontrollieren, ob es jeweils geht.

Wenns dann bei beiden Tunern geht (wenn man jeweils nur einen Tuner alleine verwendet), dann mal alles auskommentieren, und nur 1: und die folgende Zeile da lassen - das sollte nix aendern, und dann nochmal die folgende Zeile tauschen, also andere downstream frequenz ausprobieren.

Alles ziemlich nervig, aber sind halt so viele drehbare Parameter, das man da langsam schritt fuer schritt tested, sonst weiss man am Ende nicht, was man da wirklich festgestellt hat.

Quote from zillerbaer

... und bekommst eine einfache Antwort, die auch falsch sein kann.

Musste wegen "pandigital" natuerlich direkt chatgpt folgendes fragen:

Erklaere mir pananaloge Zahlen

Pananaloge Zahlen sind ein mathematisches Konzept, das häufig in der Zahlentheorie vorkommt. Es handelt sich um Zahlen, die unter bestimmten Bedingungen oder Operationen ähnliche Eigenschaften wie andere Zahlen aufweisen. Der Begriff selbst wird je nach Kontext unterschiedlich verwendet, ist aber meist mit der Idee verknüpft, strukturelle Ähnlichkeiten oder parallele Muster zu identifizieren.

Mich nevt ja auch total, wenn da die AI-Versteher dann rumlabern "Halluzinationen". Ich stell mir halt so vor, ein Matheprofessor stellt die Frage in einer Prüfung. Würden dann die Studenten die so antworten danach zum Arzt gebracht werden ? Seit wann nennt man das Halluzination, wenn man sich was ausdenkt ? *grrrrrr*

kfb77 Wenn Deine Platte 512 Byte Sektorgröße hat, dann sind das laut total_LBA_written ja wohl 330 TerraByte. Was fuer ein Modell ist das denn, mal beim Geizhals geguckt, was da angegeben ist ?

Wenn da so wie bei @MegaVOlt der Wear_Leveling_Count von 100 (frische Platte) runterzaehlt, dann sollte Deine Platte ja schon tod sein. Was oder wie dann aber das RAW_VALUE sagen soll... keine Ahnung.

SHF Siehe oben. In meiner Erfahrung, und dem was man so auf dem Internet findet scheint es besser fuer die Lebensdauer der SSD zu sein, wenn man fstrim nur z.b. woechentlich auf der Platte macht. Gerade wenn man z.b. so wie ich ein gentoo hat und da gerne mal das ganze OS wieder neu compiliert wuerde man bei "discard" mount option dauernd viele kleine bloecke trimmen und damit die controller-logic quaelen - und im schlimmsten fall irgendwelche Bloecke immer wieder benutzen.

Vielleicht macht das alles bei guter SSD Firmware am Ende keinen Unterschied...

Quote from SHF

Unicable wird durch 22KHz-Impulse gesteuert, wenn es da Fehler gibt, kann es sein dass der Umschalter nicht auf den richtigen Kanal umschaltet und die Karte deshalb keinen Empfang hat.

Welchen "Umschalter" meinst Du ? Der_Pit hat ja dazu nix gesagt, aber ich vermute mal, das da einfach bloß ein Unicable fähiger LNB im Einsatz ist. Meinst Du dann den "Umschalter" im LNB ? === Fehler im LNB ???

Quote from SHF

AFAIK kann man die Unicable-Frequenzen im VDR direkt eingeben. Ich würde mal versuchsweise die Frequenzen der beiden Karten tauschen. Wenn der Fehler dann wandert, hat der Umschalter eine Macke.

1:
0 1210

2:
1 1420

3:
2 1680

4:
3 2040

1:, 2:, 3:, 4: sind die relativen Nummern der aktivierten DVB Empfangskarten. Also wenn man da VDR ohne Argumente startet und /dev/dvb/adapter0, ... /dev/dvb/adapter3 hat, dann ist 1: für adapter0, ... 4: für adapter3. Wenn man VDR mit z.b. -D1 -D2 -D3 startet, dann ist 1: /dev/dvb/adapter1 (von -D1) usw.

0, 1, 2, 3 sind dann jeweils die Nummern der Unicable Dowstream Frequenzen. Die sind normalerweise in den LNB Dokumentationen mit 1 angefangen ausgedruckt, aber (damit einfacher ist *rotfl*) in der scr.conf eben mit 0 startend. Diese Nummern müssen korrekt zur folgenden Frequenz sein für den LNB, sonst geht gar nix - weil die Nummer dann codiert in der 22khz diseqc Unicable Signalisierung anstelle der Frequenz verwendet wird. Leider kann VDR ja nicht diese Frequenzen selbst (automagisch) rausfinden wie sonst jeder TV/STB/SATIP-Umsetzer, weils a) proprietaer ist und b) wohl nicht unbedingt von jeder PCI Karte unterstützt würde.

Auf jeden Fall würde man in der scr.conf des OP dann einfach die Zahlen 1: und 2: vertauschen wenn man die downlink Frequenzen der beiden DVB Karten tauschen will. 3: und 4: gibts in seiner config ja nicht.

Erfahrungsgemaess sind die niedrigeren Frequenzen besser im Empfang, wenn man da also einen LNB hat mit vielen Frequenzen dann kann man sich ja auch notfalls niedrigere raussuchen und verwenden. Meiner hat 24 Frequenzen, das macht schon ein paar db Unterschied.

Das da vor allem frontend 0/0 betroffen ist kann allerdings auch daran liegen, das das AFAIK das arme frontend ist mit dem VDR gerne EPG/transponder scans macht.

In der normal empfohlenen scr.conf sind keine 1:, 2:, 3: ... angegeben, dann weist der VDR die Frequenzen den einzelnen DVB Karten automatisch zu, und man weiss nie so einfach, welche Karte welche Frequenz verwendet. Allerdings nehme ich mal an, das das auch einfach der Reihe nach geht, habs allerdings nicht im source code von vdr verifiziert. Und wüsst e nicht, wie man das in irgendeinem VDR output rausfinden koennte.

Willkommen im Club. Hab gerade dieselben Probleme mit meiner DD Cine V2 6.5 quad Karte. Hab inzwischen auf EXIP 418 umgestellt, der ist sehr gluecklich mit dem Signalpegel vom LNB. Hab leider keine guten Werte von frueher von der Cine V2, von daher kann ich nicht sagen, ob sich die Karte verschlechtert hat oder der Empfang. Weils ja unicable ist weiss man leider auch nicht genau, ob so eine Karte nicht einfach nur schwierigkeiten hat, das diseqc Kommando richtig abzusetzen beim umschalten. Um das festzustellen braeuchte man richtig teuer messgeraet.