[ANNOUNCE] VDR developer version 1.7.22

  • aus der ML:

    KODI, tvh, arch x86_64, Octopus net 2 x Duoflex C/C2/T2 , NUC7i3BNH, Crucial MX300 2TB, LG LM 669S

    Linux is the best OS I have ever seen -- Albert Einstein

    Einmal editiert, zuletzt von lostinspc ()

  • Hi,
    Vielen Dank - das es immer weiter geht :]

    Ich musste zum Kompilieren, die svdrpsend.pl in svdrsend umbenennen. Ansonsten gibts einen Fehler

    Na ja - steht ja auch dort : - Removed the '.pl' suffix from all scripts (thanks to Ville Skyttä).
    Wobei ich den Vorteil daran nicht erkennen kann.


    Btw: Ich hoffe der Patch lässt nicht lange auf sich warten ;D

    VDR 1 (SD) : ASRock A330 GC, 1 GB RAM, TT- FF Karte rev. 2.3, 7'' TFT, Lirc X10 - Selbstbau Gehäuse - Suse 11.3 (64) vdr-1.7.10 diverse Plugins
    VDR 2 (HD) : MSI G41M-P25, 2 GB RAM, E6700 2x3.20GHz, Gainward GT220, 2TB HD, Lirc X10, TT S2-3600 USB, TT S2-1600, - Suse 11.3 (64) NvidiaTreiber 260.19 vdr-1.7.18 - xineliboutplugin 1.0.90 cvs, xine-lib 1.1.90 , s2-liplianin DVB Treiber

    Einmal editiert, zuletzt von rudirabbit ()

  • Hallo zusammen


    ich habe ein Problem mit der SCR Implementierung die hat ich auch schon mit dem Unicable Patch. Bisher dachte ich es läge daran das ich da beim patchen was falsch gemacht habe, aber mit der 22 hab ich das Problem immer noch.


    Und zwar habe ich 100% Auslastung in dem "tuner on frontend x" thread wenn kein Lock zu Stande kommt. Dann kann ich den VDR auch kaum mehr beenden dauer bis zu 10 Minuten bis der vdr Thread sich beendet.


    Hat jemand so ein ähnliches Problem ?

  • Na ja - steht ja auch dort : - Removed the '.pl' suffix from all scripts (thanks to Ville Skyttä).
    Wobei ich den Vorteil daran nicht erkennen kann.


    Hier die Begründung von Ville Skyttä:


    Klaus


  • Hab' ich während des Ausprobierens des SCR auch manchmal beobachtet, hatte aber nicht genug Zeit (und auch nicht wirklich eine Idee) dem nachzugehen.


    Ich werde mir das mit deinen Hinweisen mal genauer anschauen.


    Klaus

  • Und zwar habe ich 100% Auslastung in dem "tuner on frontend x" thread wenn kein Lock zu Stande kommt. Dann kann ich den VDR auch kaum mehr beenden dauer bis zu 10 Minuten bis der vdr Thread sich beendet.


    Also ich kenne das Problem nicht, würde aber evtl. an Deiner Stelle in der diseqc.conf mal das Verhalten der verschiedenen Schaltspannungen, "V" oder "v", testen.


    Es gibt da IMHO keine Faustformel, mit den S2-1600ern mußte ich "v" (13V) definieren damit es funktioniert hat, im selben VDR und am selben Unicable LNB mit der CineS2 V5.5 funktionierte das nur mit "V" (19V, meine ich).


    Regards
    fnu

    HowTo: APT pinning

  • Zitat

    Ich hab jetzt mak ein wenug mehr geforscht, und mir scheint es als ob ExecuteDiseqc mehrmals aufgerufen wird, und somit wild durcheinander diseqc Befehle gesendet werden. Ich hab einfach l ein paar Debug Meldungen eingebaut,


    im guten Fall sieht es so aus:


    Dec 5 19:23:33 DaBrazos vdr: [3257] Run ExecuteDiseqc
    Dec 5 19:23:33 DaBrazos vdr: [3257] Finished loop: 1
    Dec 5 19:23:33 DaBrazos vdr: [3257] Run ExecuteDiseqc
    Dec 5 19:23:33 DaBrazos vdr: [3257] Finished loop: 2
    Dec 5 19:23:33 DaBrazos vdr: [3257] Run ExecuteDiseqc
    Dec 5 19:23:33 DaBrazos vdr: [3257] Finished loop: 3
    Dec 5 19:23:33 DaBrazos vdr: [3257] Run ExecuteDiseqc
    Dec 5 19:25:35 DaBrazos vdr: [3257] Finished loop: 4
    Dec 5 19:25:35 DaBrazos vdr: [3257] Run ExecuteDiseqc
    Dec 5 19:25:36 DaBrazos vdr: [3257] Finished loop: 5
    Dec 5 19:25:36 DaBrazos vdr: [3257] Finished ExecuteDiseqc


    im schlechten Fall so:
    Dec 5 19:30:30 DaBrazos vdr: [3260] Finished loop: 1
    Dec 5 19:30:30 DaBrazos vdr: [3260] Run ExecuteDiseqc
    Dec 5 19:30:30 DaBrazos vdr: [3257] Run ExecuteDiseqc
    Dec 5 19:30:30 DaBrazos vdr: [3257] Finished loop: 1
    Dec 5 19:30:30 DaBrazos vdr: [3257] Run ExecuteDiseqc
    Dec 5 19:30:30 DaBrazos vdr: [3257] Finished loop: 2
    Dec 5 19:30:30 DaBrazos vdr: [3257] Run ExecuteDiseqc
    Dec 5 19:30:30 DaBrazos vdr: [3257] Finished loop: 3
    Dec 5 19:30:30 DaBrazos vdr: [3260] Finished loop: 2
    Dec 5 19:30:30 DaBrazos vdr: [3260] Run ExecuteDiseqc
    Dec 5 19:30:30 DaBrazos vdr: [3260] Finished loop: 3
    Dec 5 19:30:30 DaBrazos vdr: [3257] Run ExecuteDiseqc
    Dec 5 19:30:30 DaBrazos vdr: [3260] Run ExecuteDiseqc
    Dec 5 19:39:06 DaBrazos kernel: [ 1920.759030] INFO: task tuner on fronte:3260 blocked for more than 480 seconds.
    Dec 5 19:39:06 DaBrazos kernel: [ 1920.759050] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
    Dec 5 19:39:06 DaBrazos kernel: [ 1920.759060] tuner on fronte D f3c06e00 0 3260 1 0x00000000
    Dec 5 19:39:06 DaBrazos kernel: [ 1920.759068] e9b45e94 00200086 00000147 f3c06e00 f6fbc530 c0a8afa0 c0b51e00 c0b51e00
    Dec 5 19:39:06 DaBrazos kernel: [ 1920.759079] 1d39e956 00000147 f3c06e00 f6fbc530 c0a8afa0 c0b4dac0 1d2e821d 00000147
    Dec 5 19:39:06 DaBrazos kernel: [ 1920.759088] 00000000 00000031 f22606c0 e9b45ec0 e9b45d9c e9b45f1c 00200282 f3d02aec
    Dec 5 19:39:06 DaBrazos kernel: [ 1920.759097] Call Trace:
    Dec 5 19:39:06 DaBrazos kernel: [ 1920.759120] [<c0707d18>] __mutex_lock_slowpath+0xd8/0x150
    Dec 5 19:39:06 DaBrazos kernel: [ 1920.759129] [<c0707936>] mutex_lock+0x16/0x30
    Dec 5 19:39:06 DaBrazos kernel: [ 1920.759162] [<f80dca5e>] dvb_usercopy+0x8e/0x130 [dvb_core]
    Dec 5 19:39:06 DaBrazos kernel: [ 1920.759179] [<f80dcb1a>] dvb_generic_ioctl+0x1a/0x30 [dvb_core]
    Dec 5 19:39:06 DaBrazos kernel: [ 1920.759190] [<c0339c3e>] do_vfs_ioctl+0x7e/0x2a0
    Dec 5 19:39:06 DaBrazos kernel: [ 1920.759198] [<c0339ede>] sys_ioctl+0x7e/0x90
    Dec 5 19:39:06 DaBrazos kernel: [ 1920.759207] [<c070905d>] syscall_call+0x7/0xb
    Dec 5 19:39:06 DaBrazos kernel: [ 1920.759224] [<b7572174>] 0xb7572173
    Dec 5 19:39:06 DaBrazos kernel: [ 1920.759230] INFO: task ecmhandler 1 fi:3284 blocked for more than 480 seconds.
    Dec 5 19:39:06 DaBrazos kernel: [ 1920.759239] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
    Dec 5 19:39:06 DaBrazos kernel: [ 1920.759247] ecmhandler 1 fi D 00000147 0 3284 1 0x00000000
    Dec 5 19:39:06 DaBrazos kernel: [ 1920.759253] f6fc3e98 00200086 2db2d835 00000147 00200046 c0a8afa0 c0b51e00 c0b51e00
    Dec 5 19:39:06 DaBrazos kernel: [ 1920.759262] 2dae6de3 00000147 f3c06e00 f6eb0e70 f6da6630 ffffffff f80ef02c c07098ea
    Dec 5 19:39:06 DaBrazos kernel: [ 1920.759271] f80ef02c e9b471b0 f6fc2000 00000001 00000000 f6fc3e98 00000000 0000007b
    Dec 5 19:39:06 DaBrazos kernel: [ 1920.759280] Call Trace:
    Dec 5 19:39:06 DaBrazos kernel: [ 1920.759288] [<c0707d18>] __mutex_lock_slowpath+0xd8/0x150
    Dec 5 19:39:06 DaBrazos kernel: [ 1920.759295] [<c0707936>] mutex_lock+0x16/0x30
    Dec 5 19:39:06 DaBrazos kernel: [ 1920.759307] [<f80dca5e>] dvb_usercopy+0x8e/0x130 [dvb_core]
    Dec 5 19:39:06 DaBrazos kernel: [ 1920.759320] [<f80dcfcf>] dvb_demux_ioctl+0xf/0x20 [dvb_core]
    Dec 5 19:39:06 DaBrazos kernel: [ 1920.759330] [<c0339c3e>] do_vfs_ioctl+0x7e/0x2a0
    Dec 5 19:39:06 DaBrazos kernel: [ 1920.759337] [<c0339ede>] sys_ioctl+0x7e/0x90
    Dec 5 19:39:06 DaBrazos kernel: [ 1920.759345] [<c070905d>] syscall_call+0x7/0xb
    Dec 5 19:39:06 DaBrazos kernel: [ 1920.759354] [<b7572174>] 0xb7572173


    Ich habe aktuell 2 DVB Devices aktiv.
    Vielleicht hilft das ja.

  • ALT255


    Auch wenn Du das anders siehst, aber IMHO ist das kein Problem vom VDR, sondern entweder eines mit dem Kernel-Modul der DVB Karte oder, und das wäre mein Favorit, das eines Plugins das viele im Einsatz haben, aber keiner drüber redet ...


    Regards
    fnu

    HowTo: APT pinning

  • fnu


    Ich bin ja scheinbar nicht der einzige der das hat, siehe Beitrag von Klaus.
    Ich werde aber trotzdem mal ohne Patches und ohne Plugins außer dem dvdhddevice für die S2-6400 testen.
    Und wenn ich Zeit habe auch mal mit ner anderen Distri mit anderem Kernel.
    Eine kleine Möglichkeit besteht tatsächlich das es der 3.0.1Kernel ist, der die Probleme macht. Ich habe nämlich vor Rund 2 Wochen upgedatet. Und ich meine da ging es auch mit den Problemen los.

  • Ich bin ja scheinbar nicht der einzige der das hat, siehe Beitrag von Klaus.


    Das wollte ich damit auch nicht sagen, aber ich verwende Unicable schon eine ganze Weil, mit inzwischen betagter Software, aber kenne das Problem nicht, noch habe ich das anderweitig gehört. Aber stimmt, ihr seit zu zweit ... ;)


    Aber, und jetzt kommt's, die Gemeinsamkeit kam jetzt erst in Deinem dritten (!) Post raus, die S2-6400 die "kls" vmtl. auch im Einsatz hat.


    Regards
    fnu


    PS.: Und ja, das unterschreibe ich, es muß im VDR nicht immer der neueste Kernel sein, wozu auch, wenn der Alte fehlerfrei läuft ...

    HowTo: APT pinning

    3 Mal editiert, zuletzt von fnu ()

  • Hallo,


    ich habe bei meiner Konfiguration (TT6400 + Hauppauge NOVA-HD-S2) folgendes Problem mit dem neuen LNB-Sharing festgestellt (alle 3 Empfänger sind am selben Kabel):


    nach Einschalten eines Empfangskanals bleibt nach jeweils ca. 90s das Bild stehen, OSD geht weiterhin, nach Neuaufruf eines Kanals geht es erst mal wieder, dann der gleiche Effekt. Das kann man dann endlos wiederholen. Getestet mit purem vdr+dvbhddevice+remote,
    Mit dem bisherigen LNB-Sharing-Patch war dieses Problem nicht vorhanden.


    Folgende Log-Ausgaben dazu:

    Code
    Dec  6 16:50:14 home-05 vdr: [26405] found 3 DVB devices
    Dec  6 16:50:14 home-05 vdr: [26405] tuner 0/0 bonded with tuner 1/0
    Dec  6 16:50:14 home-05 vdr: [26405] device 1 bonded with device 2
    Dec  6 16:50:14 home-05 vdr: [26405] ERROR: device 1 already bonded with device 2, can't bond with device 3
    Dec  6 16:50:14 home-05 vdr: [26405] initializing plugin: dvbhddevice (0.0.4): HD Full Featured DVB device
    Dec  6 16:50:14 home-05 vdr: [26405] initializing plugin: remote (0.4.0): Fernbedienung
    Dec  6 16:50:14 home-05 vdr: [26405] setting primary device to 1
    Dec  6 16:50:14 home-05 vdr: [26405] assuming manual start of VDR


    Nach der Fehlermeldung in Zeile 4 kann wohl das 3. Gerät nicht korrekt mit dem 1.Kabel verbunden werden.


    Gemäß setup.conf sollte die Einstellung korrekt sein, und es sollten doch sicherlich mehr als 2 Geräte pro Kabel möglich sein.


    Code
    DeviceBondings = 1 1 1 0 0 0 0 0 0 0 0 0 0 0 0 0


    Gruß


    Karl

    VDR 2.6.6: ASUS Prime X470-PRO, Ryzen 7 5700X, 64GB, 6TB HD, GT1030, Fedora 39 Kernel 6.7 X86_64, Devicebonding 2 x 1 auf 2, TT6400, DVBSky S952 V3

    Git-Repo: gitlab.com/kamel5

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!