massenhaft Einträge Audio-/Videorepacker in syslog

    Hi,


    ich habe seit einigen Tagen merkwürdige Einträge in /var/log/syslog, wenn Aufnahmen laufen:

    Seltsamerweise tritt das Problem nur bei Aufnahmen von Pro7, insbesondere "Simpsons" auf. Die Aufnahme von "Charmed" gestern abend lief bis auf einen vereinzelten Eintrag am Anfang sauber ab.


    Achja, ich hab' seit dem Update auf 1.3.33 mit Bigpatch am 25.09. nix mehr an der Kiste geändert. ;)


    Kann mir das jemand erklären?

    VDR-User #992
    Server: Asrock N3700-ITX mit Cine S2 6.5 headless
    System: Ubuntu 22.04.LTS
    VDR: VDR 2.2.0 mit epgsearch, live, vnsiserver
    Client: Raspberry Pi v4 mit LibreElec

    Ich hab' mir heute die Kiste nochmal vorgenommen. Die Fehler entstanden nur auf dem Pro7-Transponder und nur wenn die Skystar2 benutzt wurde (auch bei Femon zu bestaunen).
    Verzweifelt hab' ich dann die Kiste runtergefahren und mal ein wenig an den DVB-Karten gewackelt. Seitdem sind die Fehler weg. Seltsam.

    VDR-User #992
    Server: Asrock N3700-ITX mit Cine S2 6.5 headless
    System: Ubuntu 22.04.LTS
    VDR: VDR 2.2.0 mit epgsearch, live, vnsiserver
    Client: Raspberry Pi v4 mit LibreElec

    hab das selbe problem



    hab eine TT 1.3 und 2x Skystar2 im linvdr 0.7 1.3.34 mit kernel 2.6.12.4 und firmware 2621.


    die meldungen kommen i.d.R. bei aufzeichnungen über die skystar auf sat1/pro7.
    könnte es am dolbydigital oder an der empfindlichen frequenz (DECT syndrom) liegen ?


    ich "vermute" aber eher einen bug im pci transfer von skystar zur tt bzw. ide, den wie hier gepostet kommt bei starker belastung noch folgende meldungen dazu


    Code
    Oct  9 00:33:09 vdrruth user.err kernel: dvb_demux_feed_del: feed not in list (type=0 state=0 pid=ffff)
Oct  9 00:33:09 vdrruth user.err kernel: dvb_demux_feed_del: feed not in list (type=0 state=0 pid=ffff)
Oct  9 00:33:09 vdrruth user.err kernel: dvb_demux_feed_del: feed not in list (type=0 state=0 pid=ffff)
Oct  9 00:33:09 vdrruth user.err kernel: dvb_demux_feed_del: feed not in list (type=0 state=0 pid=ffff)
Oct  9 00:33:09 vdrruth user.err vdr[8181]: ERROR (dvbdevice.c,698): Invalid argument
Oct  9 00:33:09 vdrruth user.err vdr[8181]: ERROR: can't set PID 511 on device 1
Oct  9 00:33:09 vdrruth user.err vdr[8181]: ERROR (dvbdevice.c,720): Invalid argument
Oct  9 00:33:09 vdrruth user.err vdr[8181]: ERROR: failed to set PIDs for channel 10 on device 1
Oct  9 00:33:09 vdrruth user.err vdr[8181]: retrying

    3x ASRock ION 330 + TT S2-3600 + Pollin X10 + Freevdr 2.0e
    2x HTPC GMC AVC-M1 + Asus M2A VM/HDMI + HVR 4000 + NVidia 8400GS + Pollin X10 + Freevdr 2.0e
    1x Asus T3-m3n8200 + Nova HD S2 + NVidia 8400GS + Pollin X10 + Freevdr 2.1
    Daten Server Gentoo_Amd64 - VDR1.4.6 - xineliboutput - streamdev-server - 4 TB Raid5 - LVM - DM-Crypt


    [Blockierte Grafik: http://device.name/publicicon2.png]

    Zitat


    das problem konnte ich durch downgraden des linvdr von 1.3.34 auf 1.3.33 beheben.
    übrigens ist repack NICHT der sündenbock, sondern er springt als letzte instanz an um den fehlerhaften mpeg strom wieder zu syncen, der durch irgendwas anderem verursacht wird.
    i.d.R. ist sowas zb. ein schlechter empfang bedingt durch die schüssel , funkstörung durch dect funktelefone oder ähnliches, bei der 1.3.34 denk ich mal ein software/treiber problem.

    3x ASRock ION 330 + TT S2-3600 + Pollin X10 + Freevdr 2.0e
    2x HTPC GMC AVC-M1 + Asus M2A VM/HDMI + HVR 4000 + NVidia 8400GS + Pollin X10 + Freevdr 2.0e
    1x Asus T3-m3n8200 + Nova HD S2 + NVidia 8400GS + Pollin X10 + Freevdr 2.1
    Daten Server Gentoo_Amd64 - VDR1.4.6 - xineliboutput - streamdev-server - 4 TB Raid5 - LVM - DM-Crypt


    [Blockierte Grafik: http://device.name/publicicon2.png]

    Hab das selbe Problem:


    Oct 21 18:51:05 VDR vdr[25341]: cAudioRepacker(0xC0): skipped 65 bytes to sync on next audio frame
    Oct 21 18:51:05 VDR vdr[25341]: cAudioRepacker(0xC0): skipped 251 bytes while syncing on next audio frame
    Oct 21 18:51:05 VDR vdr[25341]: cAudioRepacker(0xC0): skipped 325 bytes to sync on next audio frame
    Oct 21 18:51:05 VDR vdr[25341]: cAudioRepacker(0xC0): skipped 572 bytes while syncing on next audio frame
    Oct 21 18:51:06 VDR vdr[25341]: cAudioRepacker(0xC0): skipped 4 bytes to sync on next audio frame
    Oct 21 18:51:06 VDR vdr[25341]: cAudioRepacker(0xC0): skipped 576 bytes to sync on next audio frame
    Oct 21 18:51:06 VDR vdr[25341]: cVideoRepacker: found system start code: stream seems to be scrambled or not demultiplexed
    Oct 21 18:51:06 VDR vdr[25341]: ERROR: unknown picture type '6'
    Oct 21 18:51:06 VDR vdr[25341]: initiating emergency exit
    Oct 21 18:51:06 VDR vdr[25341]: cVideoRepacker: found system start code: stream seems to be scrambled or not demultiplexed
    Oct 21 18:51:06 VDR vdr[25341]: cAudioRepacker(0xC0): skipped 576 bytes to sync on next audio frame
    Oct 21 18:51:06 VDR vdr[25341]: cAudioRepacker(0xC0): skipped 516 bytes to sync on next audio frame
    Oct 21 18:51:06 VDR vdr[25341]: cDolbyRepacker: skipped 2035 bytes while syncing on next AC3 frame
    Oct 21 18:51:07 VDR vdr[25341]: cDolbyRepacker: skipped 1549 bytes to sync on next AC3 frame
    Oct 21 18:51:07 VDR vdr[25341]: cAudioRepacker(0xC0): skipped 60 bytes to sync on next audio frame
    Oct 21 18:51:07 VDR vdr[25341]: cAudioRepacker(0xC0): skipped 576 bytes to sync on next audio frame
    Oct 21 18:51:07 VDR vdr[25341]: cAudioRepacker(0xC0): skipped 96 bytes to sync on next audio frame
    Oct 21 18:51:07 VDR vdr[25341]: cAudioRepacker(0xC0): skipped 188 bytes to sync on next audio frame
    Oct 21 18:51:07 VDR vdr[25341]: emergency exit requested - shutting down
    Oct 21 18:51:07 VDR vdr[25341]: stopping plugin: osdteletext
    Oct 21 18:51:07 VDR vdr[25341]: stopping plugin: tvonscreen
    Oct 21 18:51:07 VDR vdr[25341]: stopping plugin: sc
    Oct 21 18:51:07 VDR vdr[25341]: recording thread ended (pid=25341, tid=1135610800)
    Oct 21 18:51:07 VDR vdr[25341]: cDolbyRepacker: skipped 1792 bytes to sync on next AC3 frame
    Oct 21 18:51:07 VDR vdr[25341]: TS buffer on device 2 thread ended (pid=25341, tid=1106291632)
    Oct 21 18:51:07 VDR vdr[25341]: buffer stats: 104340 (4%) used
    Oct 21 18:51:07 VDR vdr[25341]: receiver on device 2 thread ended (pid=25341, tid=1102089136)
    Oct 21 18:51:07 VDR vdr[25341]: file writer thread ended (pid=25341, tid=1122311088)
    Oct 21 18:51:07 VDR vdr[25341]: buffer stats: 177848 (3%) used
    Oct 21 18:51:07 VDR vdr[25341]: timer 1 (6 1820-1910 'nano') stop
    Oct 21 18:51:07 VDR vdr[25341]: recording thread ended (pid=25341, tid=1137712048)
    Oct 21 18:51:07 VDR vdr[25341]: TS buffer on device 3 thread ended (pid=25341, tid=1155566512)
    Oct 21 18:51:07 VDR vdr[25341]: buffer stats: 90240 (4%) used




    wer mal auf die 33er version downgraden

    SUSE 10.2, VDR 1.4.7
    PLUGINS: remote, skinoppu, dvd, mp3, osdteletext, tvonscreen, image, epgsearch, streamdev, rectstatus, screenshot
    P4 2,8GHz, 512MB, Nexus-s 2.3, Nova-S, 2xNova-S-PLUS, SP2514N, SP1614N, SP1604N, Gigabyte GA-8KNXP
    Silverstone LC10 mit eigenem 4x20 LCD und AVR-Butterfly als remote-power-on und timer und IR-code converter

    Also bin ich doch nicht blöde


    Habe das selbe Problem, hatte von 1.3.22 auf 1.3.33 und dann auf 1.3.34 geupdatet und auch nur Probleme mit dem ProSiebenAustria bzw. Sat1Austria.


    Die Aufnahmen lassen sich auch nicht weiterverarbeiten, denn die Programme die sonst immer funktionierten stürzen ab (unter WIndoof).


    Soweit ich mich an meine hastige Testreihe erinnere (habe zurzeit keine zeit zum testen) war das bei der 1.3.33 auch schon der Fall.


    Ich bin momentan wieder auf die 1.3.22 runtergegangen, da dort das Problem nie aufgetreten ist und seit ein paar Minuten auch nicht mehr erscheint, ich werds nochmal weiter beobachten.
    Über zwischenversionen nach 1.3.22 kann ich nichts sagen, da ich keine getestet hatte, die 1.3.22 lief immer super ....


    BTW: Hats mal jemand OHNE Bigpatch versucht ?


    MFG
    Marco

    Leider momentan kein VDR

    Einmal editiert, zuletzt von mbc ()

    Ich habe mir die Tage auch noch mal die Daten der Skystar2-Karte mit dem Femon-Plugin angesehen. Ab und zu habe ich da deutliche Ausschläge bei BER. Wenn ich dann das Sat-Kabel zur Skystar2 auch nur ganz leicht am Stecker berühre, ist der Fehler erstmal weg.


    Scheint wohl irgendwie auch mit grottigem Kabel/Stecker zusammenzuhängen.

    VDR-User #992
    Server: Asrock N3700-ITX mit Cine S2 6.5 headless
    System: Ubuntu 22.04.LTS
    VDR: VDR 2.2.0 mit epgsearch, live, vnsiserver
    Client: Raspberry Pi v4 mit LibreElec

    Dann wirds komisch


    Bei mir ist nur eine TT-FF Karte und zwei TT-Budgets verbaut und der Fehler tritt auf, wenn ich mit der FF tune.


    Die Kabel und verbindungen sind hier einwandfrei, außerdem hat sich seit lamgem daran nicht geändert.


    Die 1.3.22 läuft jetzt seit über einer Stunde, keine einzigen Einträge und das Satkabel bzw. sonstiges hab ich in der zwischenzeit nicht einmal angehaucht.


    Könnte eventl. ja auch sein, das der Stream nicht ganz konform ist, das kann aber nur ein Profi sagen.


    Ich vermute mal das die früheren Versionen den Stream nicht versuchen zu reparieren, aber bis jetzt war keine einzige Aufnahme von mir defekt ... ich schließe also eine Fehler in der Hardware, sowie Verkabelung hier aus.


    MFG
    Marco

    Leider momentan kein VDR

    2 Mal editiert, zuletzt von mbc ()

    also bei meinem downgrade von 1.3.34 auf 1.3.33 sind zwar die einträge nicht weg, aber bei weitem nicht mehr so brutal oft (ständig) wie bei der 1.3.34.
    konnte das ganze zumindestens bei mir aber noch soweit eingrenzen, das es cpu last abhängig ist.
    wenn ich wärend einer pro7 oder sat1 aufzeichnung eine aufnahme anschaue oder bearbeite, oder mit burn eine dvd erzeuge, also die cpu ( AMD XP2400) verhältniss mässig viel zu tun hat, dann treten die einträge im 1-3 sekunden takt auf, in der aufzeichnung sind extreme klötzchen bildung und ton hänger, die aufzeichnung ist i.d.R. anschlissend unbrauchbar.
    aber wie gesagt nur wenn die cpu mehr zu tun hat als sonst.


    hatte das nicht bzw. ist es nicht aufgefallen bei versionen < 1.3.33 und jetzt wirds tricky, mit kernel 2.6.9.


    hatte bis vor 1 woche noch eine FF 1.3 drinne mit 2x skystar2 und wegen besagten bild fehlern mir eine TT 2300 reingemacht und die 1.3 raus, die wird aber erst ab kernel 2.6.12 unterstützt, bin daher abhängig von diesem kernel bzw. den 2.6.12.4.
    mit der FF 1.3 konnte ich auch den 2.6.9 nutzen unmd da gabs komischer weise keine repack fehler, daher ist bei meinem post oben die aussage downgrade von 1.3.34 auf 1.3.33 nur halbwar, ich hatte nähmlich auch den kernel von 2.6.12 wieder auf 2.6.9 downgraded, und dann war alles wieder i.o.
    nur mit besagter TT 2300 brauch ich den kernel 2.6.12.4 und hab somit auch wieder wie geschrieben die repacks drin egal ob 1.3.33 oder 1.3.34, nur bei der 1.3.33 isses nicht ganz so extrem und nur bei parellelen cpu belastungen.


    darauf hin hab ich das board + cpu (asrocks k7 nochmalwas mit XP 2400) gegen ein msi neo mit amd 64-3000 getauscht und da treten die repacks nicht mehr auf, auch bei vielen belastungen.


    mir kommt das ganze irgendwie so vor als würden die skystars auf dem pci bus ausgebremst (cpu last) und der transfer klappt nicht mehr 100% zum board/FF , und der kernel 2.6.9 belastet das system weniger als der 2.6.12.

    3x ASRock ION 330 + TT S2-3600 + Pollin X10 + Freevdr 2.0e
    2x HTPC GMC AVC-M1 + Asus M2A VM/HDMI + HVR 4000 + NVidia 8400GS + Pollin X10 + Freevdr 2.0e
    1x Asus T3-m3n8200 + Nova HD S2 + NVidia 8400GS + Pollin X10 + Freevdr 2.1
    Daten Server Gentoo_Amd64 - VDR1.4.6 - xineliboutput - streamdev-server - 4 TB Raid5 - LVM - DM-Crypt


    [Blockierte Grafik: http://device.name/publicicon2.png]

    Einmal editiert, zuletzt von vdr_Thor ()

    nachtrag:


    ich hab den kernel 2.6.13 von mahlzeit auch mal ausprobiert, hier gibt es keine repacks, allerdings geht meine FB nicht, bzw. gibt es noch probleme mit der lirc unterstützung im 2.6.13.

    3x ASRock ION 330 + TT S2-3600 + Pollin X10 + Freevdr 2.0e
    2x HTPC GMC AVC-M1 + Asus M2A VM/HDMI + HVR 4000 + NVidia 8400GS + Pollin X10 + Freevdr 2.0e
    1x Asus T3-m3n8200 + Nova HD S2 + NVidia 8400GS + Pollin X10 + Freevdr 2.1
    Daten Server Gentoo_Amd64 - VDR1.4.6 - xineliboutput - streamdev-server - 4 TB Raid5 - LVM - DM-Crypt


    [Blockierte Grafik: http://device.name/publicicon2.png]

    Also unter 2.6.13 geht schon Lirc zu mindest unter dem Suse 10 Kernel !! aber mal was anderes gefragt auch wenn es vielleicht nicht ganz dazu gehört ..



    Könnt ihr noch optimal in DD 5.1 hören ? früher ging es bei mir ohne Probleme und jetzt : unterbrechungen , mal bricht DD ganz zusammen ,sprich kein Ton mehr und dazu Bildartefakte ..also an der Firmware kann es nicht liegen sondern mehr an der VDR Version oder an den PLugIns .


    Wie immer steht im Log nix :(




    I30R6










    VDR











    Hardware : GA-EP35-DS3L, C2Q Q6700 , 3GB DDR2 , Palit GT240, 250GB System & 500GB Video,
    Mystique-CaBix C2,TT Budget C-1501,Airstar 2, Fernbedienung X10
    Software : gen2vdr, Kernel 3.8.10, vdr 2.0.1
    PlugIns : audiorecorder,femon,admin,yacoto..
    Ausgabe: softhddevice

    hab eben dr.seltsams kernel 2.6.13.4 für linvdr getestet und hatte immer noch die repack meldungen im log.


    hab darauf hin nochmal mahlzeit's kernel 2.6.13 ohne lirc inst. und da sind keine log einträge, aber bei genauem hinsehen musste ich vestellen das die aufnahmen auch fehlerhaft sind, also das selbe nur in grün bzw. ohne repack logeintrage.
    bei dem kernel ist mir auch aufgefallen das der vdr sehr träge ist bzw. auch die consolen befehle nur sehr träge verarbeitet werden.
    irgendwas zieht hier unglaublich cpu lasst, top schweigt sich leider tot.


    irgendwas verbräht unnötig cpu last, nur was? vieleicht spackt auch mein asrocks board rum, hatte schon einmal bei einem anderen älteren probleme mit dem onboard ide controller, dma fehler ohne ende, da war was am board futsch.


    werde mein board gegen ein anderes ersetzen die tage.

    3x ASRock ION 330 + TT S2-3600 + Pollin X10 + Freevdr 2.0e
    2x HTPC GMC AVC-M1 + Asus M2A VM/HDMI + HVR 4000 + NVidia 8400GS + Pollin X10 + Freevdr 2.0e
    1x Asus T3-m3n8200 + Nova HD S2 + NVidia 8400GS + Pollin X10 + Freevdr 2.1
    Daten Server Gentoo_Amd64 - VDR1.4.6 - xineliboutput - streamdev-server - 4 TB Raid5 - LVM - DM-Crypt


    [Blockierte Grafik: http://device.name/publicicon2.png]

    Also um die Sache einmal klar zu stellen


    Ich benutze seit eh und je den 2.4.20 und da traten die Probleme seit 1.3.33 (die erste nach 1.3.22) auf.


    Ich bezweifele das es an irgendeiner Hardware oder einem Kernel liegt, dies kann man logisch ausschliessen.


    Die einzigen Punkte die bleiben die bei allen identisch sind sind:


    1. Die Streams vom Sender sind defekt --> dazu müßte man die analysieren
    2. Die Streams wurden geändert und VDR hat ein Problem damit


    Ich werde die Aufnahmen vom 1.3.22 mal umwandeln und dann das Ergebnis hier posten, sollten da dann keine Probleme auftauchen liegt es definitiv an der VDR-Version, bzw. an einer dortigen Änderung die sich negativ auswirkt.
    Ausführliche Ergebnisse kann ich jedoch erst nächstes Wochenende liefern ... der Schnelltest verlief aber schon einmal sehr vielversprechend, zumal die Probleme bei mir erst auftraten als ich den VDR upgedatet hatte ...


    MFG
    Marco



    NACHTRAG:
    Habe gerade mal eben kurz eine Aufnahme umgewandelt und es gabe keine Probleme, im Log des VDR tauchten seit der Umstellung auf die 1.3.22 keine Fehler mehr auf, das Umwandeln ging problemlos und ohne Fehler.
    Eine Hörprobe von ca. 10 Minuten brachte auch keine Probleme zu Tageslicht.

    Leider momentan kein VDR

    2 Mal editiert, zuletzt von mbc ()

    Diese Problem ist bei mir seit Samstag auch ständig aufgetreten.


    Ich habe die dummer Vermutung, dass es mit dem Wetter zusammenhängt, da hier zumindest öfter Nebel und Gewitterwolken drüber hängen ..... und das führt bei nicht optimal ausgerichteter Schüssel scheinbar zu diesen Problemen.


    vdr 1.3.34 scheint den Stream wohl genauer zu prüfen und bei zu vielen Fehlern in der Aufnahme einen Reset auszulösen. Ich habe wieder auf 1.3.23 downgraded und da passiert das deutlich seltener (aber es passiert).



    Kann diese Theorie jemand verfifizieren oder falsifizieren??


    cu,
    Bernd

    --
    yavdr 0.6.1, Case: Antec Veris Remote, Mainboard: ASUS M5A78L-M/USB3, DVB-S: 2 x TT S2-3200
    Graveyard: Asus pundit, M4N78-AM V2, TeVii S646

    2 Mal editiert, zuletzt von befi ()

    sieht so aus als wenn die Neuerungen von Reinhard Nissl die Probleme verursachen:


    1.3.26:

    Code
    - Implemented cVideoRepacker in remux.c to make sure every PES packet contains
  only data from one frame (thanks to Reinhard Nissl).


    1.3.27:

    Code
    - Disabled cVideoRepacker in remux.c, because it has caused several problems
  during recording. If you want to test (and maybe debug) it, activate the line


  //#define TEST_cVideoRepacker


  in remux.c.


    1.3.28:

    Code
    - Reactivated cVideoRepacker in remux.c after some fixes (thanks to Reinhard Nissl).


    1.3.30

    Code
    - Fixed cVideoRepacker to better handle errors in data (thanks to Reinhard Nissl).


    1.3.31

    Code
    - Implemented cAudioRepacker for better handling of audio PES packets (thanks to
  Reinhard Nissl).


    1.3.32

    Code
    - Fixed syncing in cRepacker (thanks to Reinhard Nissl).


    wer weiss, ob`s nicht noch mehr Bugs gibt...


    Man müsste
    #define TEST_cVideoRepacker
    und
    #define TEST_cAudioRepacker
    in remux.c mal auskommentieren und VDR neu compilieren. Fragt doch Cody mal, ob er das als Test macht. Ich komme wohl erst am Wochenende dazu.

    VDR1: ACT-620, Asus P8B75-M LX, Intel Core i3-3240, 4 GB DDR3 RAM 1600 MHz, passive Geforce GT1030 von MSI, Sandisk 2TB SSD, 2xWinTV DualHD, Atric-IR-Einschalter. SW: Xubuntu 20.04 auf 64GB Sandisk SSD.

    VDR2: Odroid N2+ mit CoreELEC und Ubuntu in chroot, WinTV DualHD

    VDR3: Tanix TX3 mit CoreELEC und Ubuntu in chroot, WinTV DualHD

    Einmal editiert, zuletzt von Dr. Seltsam ()

    ich hab gestern mein ASRocks K7VT4pro board mit AMD XP 2400 CPU durch ein neues MSI K8N Neo2 board mit AMD 64-3000 CPU ersetzt. ich hab jetzt KEINE repack einträge mehr wenn ich wie vorher beim alten board last erzeuge (2 Dolby Sender Aufzeichnen, NOAD, eine Dolby aufzeichnung abspielen, alles gleichzeitig).


    ok ich stell jetzt mal folgende vermutung auf:


    die repack funktion benötigt im laufe der versions nummern immer mehr cpu leistung, bekommt es diese nicht, vermehren sich die repack meldungen im log.


    mein ausgetauschtes asrocks board hat einen via vt8237 chipsatz, der ist bekannter maßen nicht gerade cpu entlastent bei festplatten zugriffe.
    was früher bei alten vdr versionen und somit auch repack versionen noch gelangt hat, scheint bei den aktuelleren version bedingt durch mehr cpu last, beim zusammen spiel mit festplatte und budget sat karten nicht mehr zu reichen.


    fazit, mehr cpu power oder repack wie von dr.seltsam vorgeschlagen erst mal rausnehmen, bzw. vom autor entbuggen lassen.

    3x ASRock ION 330 + TT S2-3600 + Pollin X10 + Freevdr 2.0e
    2x HTPC GMC AVC-M1 + Asus M2A VM/HDMI + HVR 4000 + NVidia 8400GS + Pollin X10 + Freevdr 2.0e
    1x Asus T3-m3n8200 + Nova HD S2 + NVidia 8400GS + Pollin X10 + Freevdr 2.1
    Daten Server Gentoo_Amd64 - VDR1.4.6 - xineliboutput - streamdev-server - 4 TB Raid5 - LVM - DM-Crypt


    [Blockierte Grafik: http://device.name/publicicon2.png]


    Ich benutze Linvdr 07 + Cody's Patch und habe auch die LOG Einträge, allerdings mit dem Problem das der Ton des öfteren ausfällt.
    Habe nun den VDR neu kompiliert und wie oben beschrieben die Statements in der remux.c (nicht transfer.c) auskommentiert.
    Zur Zeit (30 min) habe ich keine LOG Einträge mehr und ebenfalls kein Tonprobleme. Mit der VDR Binary (mit dem cAudio/VideoRepacker) hatte ich vorher im spez. auf SAT1 relativ schnell keinen Ton.
    Werde dies jetzt mal die nächsten Tage beobachten ob dies auch längerfristig eine Besserung bringt.


    Sehe ich es richtig das die LOG Einträge Infos sind (?) mit dem Resultat das versucht wird den Datenstrom zu reparieren/synchronisieren ?
    Ich muss dazu sagen das ich nicht den besten Empfang hier mit DVB-T habe. Deswegen habe ich mir jetzt eine Airstar2 bestellt die hoffentlich einen besseren Empfang als meine jetztige TT Karte hat (?).


    Gruss,


    Chuck



    [EDIT]
    Beim Umschalten bekomme ich noch folgende Fehlermeldungen (die wohl auf meinen schlechten Empfang zurückzuführen sind) allerdings ohne folgenden (nach ein paar Minuten) Tonausfall, sondern nur einem "Knacksen" beim Umschalten.


    Code
    Okt 25 22:13:47 linvdr user.info vdr[8632]: switching to channel 8
Okt 25 22:13:47 linvdr user.debug vdr[8855]: transfer thread ended (pid=8855, tid=106507)
Okt 25 22:13:48 linvdr user.debug vdr[8632]: cTS2PES got 1 TS errors, 3 TS continuity errors
Okt 25 22:13:48 linvdr user.debug vdr[8632]: cTS2PES got 0 TS errors, 3 TS continuity errors
Okt 25 22:13:48 linvdr user.debug vdr[8632]: buffer stats: 40608 (1%) used
Okt 25 22:13:48 linvdr user.debug vdr[8632]: buffer stats: 0 (0%) used

    1- yavdr 0.5 - DVB-C
    1- VDR-1.7.14 - Xine Pugin - XBMC - DVB-C
    2- Activy 300 mit Gen2VDR V2

    Einmal editiert, zuletzt von vdrchuck ()

    ups - klar, remux.c -hab`s gerade korrigiert.
    Der repacker sollte eine Verbesserung sein, und Logmeldungen sollten außer beim Umschalten nicht auftreten. Beim einem gesunden Stream (=guter Empfang) hat der repacker m.E. auch etwas zu tun, nur dass er keine Meldungen liefert. Die CPU-Last habe ich noch nicht verglichen.

    VDR1: ACT-620, Asus P8B75-M LX, Intel Core i3-3240, 4 GB DDR3 RAM 1600 MHz, passive Geforce GT1030 von MSI, Sandisk 2TB SSD, 2xWinTV DualHD, Atric-IR-Einschalter. SW: Xubuntu 20.04 auf 64GB Sandisk SSD.

    VDR2: Odroid N2+ mit CoreELEC und Ubuntu in chroot, WinTV DualHD

    VDR3: Tanix TX3 mit CoreELEC und Ubuntu in chroot, WinTV DualHD

    beim Umschalten sind die Meldungen normal.


    Die Airstar2 hat eine exzellente Empfangsleistung!

    VDR1: ACT-620, Asus P8B75-M LX, Intel Core i3-3240, 4 GB DDR3 RAM 1600 MHz, passive Geforce GT1030 von MSI, Sandisk 2TB SSD, 2xWinTV DualHD, Atric-IR-Einschalter. SW: Xubuntu 20.04 auf 64GB Sandisk SSD.

    VDR2: Odroid N2+ mit CoreELEC und Ubuntu in chroot, WinTV DualHD

    VDR3: Tanix TX3 mit CoreELEC und Ubuntu in chroot, WinTV DualHD

    Ich habe das selbe Problem mit einer Technisat Cablestar2.


    Beim live schauen fällt nichts auf, nur die Aufnahmen funktionieren teilweise nicht. Obwohl der Timer anzeigt es wird aufgenommen, werden nur die ersten Minuten gespeichert.

    VDR 1.7.15 - Debian Squeeze/Kernel 2.6.32
    Rebach-Gehäuse, Intel Atom330, Extension HD, Technisat Cablestar2

Jetzt mitmachen!

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

Benutzerkonto erstellen Anmelden