tvmovie2vdr robuster machen mit hoerzu/epgdata.com ?

  • Ich hab kaum Ahnung von Perl, würde aber denoch gern ein paar Sachen gerne am tvmovie2vdr ändern wollen. Vielleicht gibts hier ja konstruktive Vorschläge :D


    1. Abbrüche wegen leerer Files: Wenn der Download korrupt ist stirbt es ,da immer etwas von epgdata.com zurück kommt auch was, wenn kein File da ist.


    Code
    print "downloading $filenamezip\n";
       my $dummy = GetContent("$hoerzuurl$days"."&pin=$hoerzupin","$downloadprefix$filenamezip",0,0);
          eval 'use Archive::Zip qw( :ERROR_CODES :CONSTANTS )';
          my $zip = Archive::Zip->new();
    
    die 'read error' unless $zip->read("$downloadprefix$filenamezip") == AZ_OK;
          my @xmlfiles = $zip->membersMatching( "$now_string_.*\.xml" );


    Meine Fragen dazu:
    1.1 Was passiert wenn kein Netz da ist, sprich GetContent fehlschlägt ?
    Er steigt dann irgendwann aus nach retries.

    1.2 Wie kann ich anstatt die 'read error' das entsprechende File löschen ?
    Dann würde wenigstens beim nächsten Run wieder versucht das File zu laden anstatt das man manuell eingreifen muss. Noch schöner wäre natürlich wenn er anstatt zu sterben, das was er hat verarbeiten würde.


    Das ist unten ja schon beschrieben.


    2. Verarbeitung der Bilder


    Hintergrund: wenn er Bilder speichern soll ($writeimages == 1) braucht er gut den dreifachen Speicher, als normal. Ich bin mir nicht sicher, aber mir scheint als wenn er alle dekomprimierten zip's dann im Speicher behält, anderseits lese ich was anderes im Code, aber ich hab auch kein Plan davon



    Bei diesem Code dürfte doch nicht bei jedem Tag 50-80 MB mehr in den Speicher kommen. :( Funktioniert hier Archive::Zip evtl nicht so das er es nur einmal im Speicher behält und entpackt wenn angefragt sondern mehrfach neu in in den Arbeitsspeicher dekomprimiert vorhält ?


    Würde mich über eine rege Teilnahme an der Diskussion freuen. ;)

    VDR User: 87 - LaScala LC14B - LG/Phillipps 6,4" VGA Display | Asrock H61/U3S3 | G630T | 1x 16GB Mobi Mtron 3035 1x WD 750GB 2,5" |1x L4m DVB-S2 Version 5.4

    Einmal editiert, zuletzt von steffen_b ()

  • Am Speicherverbrauch lässt sich wohl nicht so leicht was ändern. Zu 1.) hab ich mir nun was zusammenkopiert ;)



    Anstelle des "die 'read error' unless $zip->read("$downloadprefix$filenamezip") == AZ_OK"


    scheint zu funktionieren. Damit könnte man dann theoretisch Daten ziehen bis keine mehr kommen. Allerdings rennt man dann noch eher in das Problem Nummer 2 ;)

    VDR User: 87 - LaScala LC14B - LG/Phillipps 6,4" VGA Display | Asrock H61/U3S3 | G630T | 1x 16GB Mobi Mtron 3035 1x WD 750GB 2,5" |1x L4m DVB-S2 Version 5.4

  • Auch wenn keinen weiter interessiert, mache ich hier mal weiter ;)


    XML::Twig scheint die Lösung. Relativ einfacher Zugriff auf die Elemente und Streamprocessing.


    Hab mir mal zum testen was zusammengeschustert. Braucht nahezu null Speicher und eine Minute für die Datei ohne Laden.


    Code
    PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
    14804 root      25   0 12216 9348 1908 R 99.6  1.9   0:23.57 test.pl
    
    
    real    0m55.567s
    user    0m54.033s
    sys     0m0.830s


    Keine Ahnung ob das jetzt schnell oder langsam ist. Wenigstens spiel ich mal mit Perl rum ;)



    Da das verarbeiten im Stream in der sub passieren muss nach meinem Verständnis kann man so die Bilder nicht mehr verarbeiten in der Schleife. Mit nem Array und ner Schleife darüber könnte man sie später in einem Rutsch machen.


    Anyway - nur für mich ist der Aufwand zu groß und Twig ist da nicht grad nen Drop-in replacement. Mir geht da unter anderem auch ab welche Variablen wo sichtbar sind.



    BTW: http://perlmeister.com/snapshots/200508/index.html

    VDR User: 87 - LaScala LC14B - LG/Phillipps 6,4" VGA Display | Asrock H61/U3S3 | G630T | 1x 16GB Mobi Mtron 3035 1x WD 750GB 2,5" |1x L4m DVB-S2 Version 5.4

    3 Mal editiert, zuletzt von steffen_b ()

  • Hi,


    es ist nicht so, das es keinen interessiert.
    Ich benutze EPFdata.com. Und die von Dir genannten Probleme nerven schon etwas. Daher bin ich schon interessiert.
    Nur hab ich von perl kaum eine Ahnung. Deswegen bin ich da erstmal nicht die große Hilfe.


    Grüße

  • Ich bin da auch inzwischen 2 Schritte weiter.


    Twig ist unter anderem auch die Lösung die vom xmltv grabber benutzt wird um es zu parsen. Vorteil ist das er nahezu 0 Speicher während der Verarbeitung braucht, da alle schon bearbeiteten Bereiche gleich wieder im Speicher freigegeben werden. Zweiter Vorteil ist das Twig sehr Perl like ist, d.h. man muss sich wenig mit XML auseinandersetzen. Ich habe jetzt aber angefangen ein XSL zu schreiben um die Daten zu verarbeiten. Braucht etwas mehr Speicher (ca 60-80MB) - ist dafür einiges schneller (Ein Tag für ca 40 Sender = 22 Sekunden) - Insgesamt sollen momentan wohl 130 Sender im Paket sein und die letzten Tage gab es 18 Tage im Voraus. Die 130 Sender sind nicht alle interessant für jeden. 45 Premiere Sender, ne Ecke an Sendern die wohl nur im Kabel sind oder anderen Sat's als Astra (So um die 30), aber ich bin da auch kein Massstab ;)

    VDR User: 87 - LaScala LC14B - LG/Phillipps 6,4" VGA Display | Asrock H61/U3S3 | G630T | 1x 16GB Mobi Mtron 3035 1x WD 750GB 2,5" |1x L4m DVB-S2 Version 5.4

  • Also ich nutze von EPGdata nur so ca. 15 Sender.


    Mich hat schon die ganze Zeit gewundert, was tvm2vdr da so lange auf den Files treibt. Weil der macht 100% CPU-Last und das parsen dauert ewig. Wenn das schneller geht, das wär natürlich genial.
    Speicherverbrauch ist mir relativ egal. Der VDR hat 2 Gig drin.


    Und 18 Tage? Liest Du jetzt einfach bis nichts mehr kommt?
    Ich mach aktuell immer 14 Tage.

  • Momentan ist das alles mehr proof of concept und ich habe auch noch nicht die Extra Felder integriert. Zum testen habe ich mir ein paar Shellscripte gebaut und die lesen in der Tat bis nichts mehr kommt. Pro Tag sind ca 7-8000 Einträge zu verarbeiten - also nicht gerade wenig. libxslt/xsltproc sind da wirklich einiges schneller. Momentan scheint die Geschwindigkeit abhängig von der Anzahl Sender zu sein ... Bei 17 Sendern:


    Code
    real 0m9.583s
    user 0m8.491s
    sys 0m0.245s


    Ich bastel erstmal ein wenig weiter. xslt ist ein anderer Programmieransatz - von sofern kann es sein das da noch Raum für mehr Geschwindigkeit ist. Momentan laufe ich für jeden Sender über alle Elemente. Andererseits sind 10-20 Sekunden auch akzeptabel :)

    VDR User: 87 - LaScala LC14B - LG/Phillipps 6,4" VGA Display | Asrock H61/U3S3 | G630T | 1x 16GB Mobi Mtron 3035 1x WD 750GB 2,5" |1x L4m DVB-S2 Version 5.4

    Einmal editiert, zuletzt von steffen_b ()

  • Zitat

    Original von steffen_b
    Ich bastel erstmal ein wenig weiter. xslt ist ein anderer Programmieransatz - von sofern kann es sein das da noch Raum für mehr Geschwindigkeit ist. Momentan laufe ich für jeden Sender über alle Elemente. Andererseits sind 10-20 Sekunden auch akzeptabel :)


    Unter der Voraussetzung, dass du aktuell pro sender über die XML-Datei
    gehen musst, wäre eine Kombination aus Sax-Parser und XSLT sinnvoll.
    Der SAX-Parser, in C implementiert, zerteilt die Datei in 1 Datei pro Sender.
    Dann loopen wir über die Dateien und XSLT geht nur noch einmal über jede,
    jetzt deutlich kleinere Datei. Natürlich könnte man dann auch alles über
    SAX machen, aber wir würden die Flexibilität von XSLT verlieren. Es ist sogar denkbar das der SAX-Parser den Abschnitt der XML-Datei für einen Sender im Speicher hält und wenn er komplett ist, dem XSLT-Parser
    per Memory übergibt. Das fetzt dann wirklich. Bei der Gelegenheit könnte sich
    der SAX-Parser auch um die Zuordnung der Bilder zu den Events kümmern und
    wir bräuchten keinen Extra-XSLT-Lauf wie ich ihn noch beim TVM2VDR-Plugin
    brauche. Was hälst du davon?


    Gerald


    HP Proliant MicroServer Gen8, Xeon E3-1230, 12 GB RAM, 3xWD red 2TB im RAID 5, 2xSundtek MediaTV Home DVB-C/T, L4M TWIN-C/T, Ubuntu Server 14.04.1, Plex Media Server
    Samsung UE55H6470

  • ich denke mir fehlt momentan einfach noch ein wenig Erfahrung ;)


    Siehe: http://www.jenitennison.com/xslt/grouping/muenchian.html


    Sprich ich groupe auf die Sender Id und matche dann die Kanäle. Dann laufe ich nicht 40 mal durch 8000 Einträge sondern 130 mal durch 40 oder wieviel auch immer. Das dürfte sehr viel weniger Rechenzeit kosten und auch nicht mehr die Geschwindigkeit bei mehr Kanälen runterziehen. Bezüglich der Bilder bin ich mir nicht schlüssig. Da die Bilder oft pro Tag bleiben, würde man einiges an rechenzeit sparen wenn man nur neue Bilder umrechnen müsste (ich meine das resizen) - selbst wenn sich die Daten ändern. Für den jetzigen Ansatz würde sich nen Sax Parser nicht lohnen. Und wenn man einfach alle Bilder nimmt und die nur mit der event id verknüpfen muss ohne auf Kanäle zu filtern lohnt sich der SAX auch nicht.

    VDR User: 87 - LaScala LC14B - LG/Phillipps 6,4" VGA Display | Asrock H61/U3S3 | G630T | 1x 16GB Mobi Mtron 3035 1x WD 750GB 2,5" |1x L4m DVB-S2 Version 5.4

  • Zitat

    Original von steffen_b
    Für den jetzigen Ansatz würde sich nen Sax Parser nicht lohnen. Und wenn man einfach alle Bilder nimmt und die nur mit der event id verknüpfen muss ohne auf Kanäle zu filtern lohnt sich der SAX auch nicht.


    Nur wie willst du die Verknüpfung machen? Sicher könnte man das
    downsizen generalisieren, aber das Umbenennen der Bilder wirst du wohl
    mit xslt nicht hinbekommen und die Information in die C-Schicht wirst Du
    im selben Durchlauf wohl auch nicht zurückgeben können. Was ich meine ist,
    du könntest vielleicht im Augenblick weniger Gehirnschmalz in die Gruppierung
    stecken, als in die Formatierung der Events, so dass du mir etwas Zeit gibst
    bis ich dich mit dem SAX-Parser eingeholt habe, der die XML-Datei zerlegt.


    Gerald


    HP Proliant MicroServer Gen8, Xeon E3-1230, 12 GB RAM, 3xWD red 2TB im RAID 5, 2xSundtek MediaTV Home DVB-C/T, L4M TWIN-C/T, Ubuntu Server 14.04.1, Plex Media Server
    Samsung UE55H6470

  • Nur so als update - das xslt ist soweit fertig - ich benutze das momentan zusammen mit nem Perl und Shellscript um die Daten zu laden. Geht natürlich nur ohne Bilder auf die Art und Weise - aber ich kann enigstens die Früchte meiner Arbeit geniessen. Momentan klaut mir das Perlskript die Umlaute ... xsltproc machts aber richtig. Das xslt dürfte in gda's svn zu finden sein.


    Eine Diskussion mit Gerald und lesen im Netz hat mir gezeigt das nen Sax Parser das bessere Werkzeug wäre für die Daten - und sollte am Besten direkt in den VDR die EPG Daten schmeissen. Sprich es sollte C++ sein. Da Gerald da wenig Zeit hat und ich erstmal ne Lernkurve zu bewältigen habe wird das noch ne Weile dauern.


    Beispiel:

    VDR User: 87 - LaScala LC14B - LG/Phillipps 6,4" VGA Display | Asrock H61/U3S3 | G630T | 1x 16GB Mobi Mtron 3035 1x WD 750GB 2,5" |1x L4m DVB-S2 Version 5.4

    2 Mal editiert, zuletzt von steffen_b ()

  • mal was anderes Steffen, bekommst du unter dem Link für die updates gescheite Daten? - oder gibst da nen anderen Link?


    Wir machen da gerade ein paar Tests drauf.


    Grüße Christian

    CKone: yavdr-ansible/18.04 LTS/2.4.1/kodi18 auf Intel DH67BL, Intel Celeron G540, 2x 2GB Kingston DDR3, Zotac GT630 1GB, S2-1600, Ocz Agility 3 60GB, LG GH24NS DVD, 15.6" Selbstbau TFT, Harmony 665, CIR Selbstbau - das Ganze im Silverstone SST-SG03B
    CKtwo: yavdr-ansible/18.04 LTS/2.4.1/kodi18 auf Intel DH67BL, Intel Celeron G1610, 2x 2GB Corsair DDR3, Zotac GT630 1GB, TT S2-1600, Ocz Vertex 2 50 GB, 92 Kanal Seduatmo, Harmony 665, atric USB
    CKthree: yavdr-ansible/22.04 LTS/2.6.1/kodi19.3 auf Intel NUC, Celeron J4005, UHD Graphics 600, 4GB Crucial DDR4, Ocz Vertex2 50 GB, Harmony 350

    PowerEdge: Ubuntu Server 16.04 LTS / VDR 2.4.1 auf Dell PowerEdge T20, Xeon E3-1225 v3, 16GB ECC DDR3, 2x Cine S2 V6 mit Duoflex, Samsung 840 EVO 120GB, 3x WD White WD80EZAZ 8TB in SW Raid5



  • Moin,


    Ja ich bin noch dran. Wie gesagt habe ich einiges zu Lernen was es ziemlich langsam macht. Stand der Dinge:


    Das Einlesen funktioniert schonmal. Die Ausgabe muss noch ein wenig aufgehübscht werden. Es sind noch etliche Stellen im Code wo Fehler nicht abgefangen werden sowie Pfade die noch hardcoded sind. Was schon abzusehen ist: Pro File befinde ich mich momentan noch unter einer Sekunde bei der XML Verarbeitung, also 15 Sek hier für eine 20-fache Loop. Speicherverbrauch ist für nen Bruchteil einer Sekunde auf 80MB, im Schnitt aber deutlich weniger. Bevor ich ein Plugin draus mache will ich den Download noch implementieren - also Umzug zum Plugin also ziemlich am Ende. Benutzen tue ich jetzt libxml2 mit der Xmltextreader API. (Wens interessiert ;))


    Also - es geht langsam voran (langsamer als ich es gerne gerne hätte, aber jeder fängt mal klein an und bin schon stolz soweit ;)) Die Luft anhalten solltest du aber nicht ;)


    Pflegen tue ich es hier:
    http://svn.origo.ethz.ch/wsvn/…vm2vdr/trunk/epgdata2vdr/


    Angehängt habe ich auch nochmal das xsl - falls das jemand interessiert kann ich den Rest mal aufräumen und zusammenpacken was ich dafür benutze (so kann man wahrscheinlich nicht viel anfangen). Das XSL braucht ca 2.5 min für einen Satz von 18 Files.


    Die Flexibilität des xslt habe ich nun komplett aufgegeben, aber da das Quellformat weitestgehend feststeht passt das schon, für ne Ausgabeformatänderung muss man dann rekompilieren.


    Code
    # time for i in `seq 0 19` ; do ./test 20090303_20090303_de_qy.zip > test.epg ; done
    
    
    real  0m15.653s
    user  0m13.907s
    sys 0m0.961s



    Ah encodinghandling fehlt auch noch ;)


    EDIT: Und Geralds Idee kapier ich jetzt erst richtig. Anyway so lese ich jetzt auch die Dateien aus der include.zip für genre und category und man könnte auch einige Sachen später übersetzen

  • Ich schau mir das mal an.
    Wenn die Laufzeiten und Speicherverbrauch so sind wie Du sagst, dann ist das der absolute Hammer.


    Ich bin grad wieder dabei auf einem TestVDR epg4vdr bzw. tvm2vdr aufzusetzen um die Daten von epgdata.com einzulesen. epg4vdr liegt bei 2 Wochen EPG fast schon im Stundenbereich von der Laufzeit her. Und lastet den Rechner (1400er PIII) dabei voll aus. D.h hier kriegt es nur 50% CPU, weil es ein Budget System ist.
    tvm2vdr bringt es auch auf lange Laufzeiten und hat ja bekanntlich einen irrwitzigen Speicherverbrauch. Dagegen sind Deine 80 MB geradezu lächerlich.


    Das hört sich also schon alles sehr vielversprechend an. Als Plugin wäre natürlich das absolute Hit. Mir würde es schon als externes Tool reichen.


    Grüße

  • Zitat

    Original von HTPC-Schrauber
    tvm2vdr bringt es auch auf lange Laufzeiten und hat ja bekanntlich einen irrwitzigen Speicherverbrauch.


    Du meinst doch wohl nicht mein Plugin, oder doch? Ich hatte mich für den Namen tvm2vdr für mein Plugin entschieden, weil ich dachte der Perl-Skript heißt tvmovie2vdr, aber leider wird hier immer alles vermischt.


    Gerald


    HP Proliant MicroServer Gen8, Xeon E3-1230, 12 GB RAM, 3xWD red 2TB im RAID 5, 2xSundtek MediaTV Home DVB-C/T, L4M TWIN-C/T, Ubuntu Server 14.04.1, Plex Media Server
    Samsung UE55H6470

  • Ich versuch mal die Ausgabe zu vervollständigen dieses Wochenende. Dann kann man den Part schonmal Standalone verwenden.


    Grössere Sachen die noch fehlen sind:
    * Encoding (iconv)
    * Download (libcurl)
    * Plugin Integration


    Kleinere Sachen sind das Errorhandling - momentan crasht das Programm wenn etwas nicht passt ;)


    Ansonsten ist mein Ziel natürlich das ganze als Plugin zu integrieren. Nur RL kommt halt zuerst :) Und das Lernen braucht auch seine Zeit - Auf jedenfall macht es Spaß. In einigen Wochen habe ich sicher auch das Plugin fertig.

    VDR User: 87 - LaScala LC14B - LG/Phillipps 6,4" VGA Display | Asrock H61/U3S3 | G630T | 1x 16GB Mobi Mtron 3035 1x WD 750GB 2,5" |1x L4m DVB-S2 Version 5.4

Jetzt mitmachen!

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