Posts by heifisch

    sqlite3 /dev/shm/tvscraper2.db

    Und dann, beim sqlite prompt:

    select season_number, episode_number, episode_absolute_number, episode_name from tv_s_e where tv_id = -364707;


    Wenn man die Datenbank direkt mit einem String wie "Der große Eisen" abfragen möchte, könnte man das so machen?


    Code
    1. sqlite3 /dev/shm/tvscraper2.db
    2. SELECT DISTINCT t1.movie_name_cache, t2.season_number, t2.episode_number, t2.episode_absolute_number, t2.episode_name FROM cache AS t1,tv_s_e AS t2 WHERE t2.tv_id=t1.movie_tv_id AND t1.movie_name_cache LIKE "%Der große Eisen%";
    3. der große eisenbahnraub 1963|1|1|0|Die Geschichte der Räuber
    4. der große eisenbahnraub 1963|1|2|0|Die Geschichte der Polizisten


    Hier habe ich noch einen Duplikatsfehler, dem ich nachgehen möchte... aber jetzt weiß ich ja, wie ich da ran gehen muss

    Nachdem ich in der Datenbank mal die Einträge geändert habe, stimmen die tvscraper-Daten und die Episoden werden korrekt angezeigt:



    Also wie es aussieht, wurden die Einträge in der Datenbank nicht durch die Änderungen der info-Datei ersetzt.

    "Folge *" hatte ich mal bei einem älteren Test in der info stehen...

    sqlite3 /dev/shm/tvscraper2.db

    Und dann, beim sqlite prompt:

    select season_number, episode_number, episode_absolute_number, episode_name from tv_s_e where tv_id = -364707;

    Code
    1. sqlite> select season_number, episode_number, episode_absolute_number, episode_name from tv_s_e where tv_id = -364707;
    2. 1|1|0|Folge 1
    3. 1|2|0|Folge 2
    4. 1|3|0|Folge 3
    5. 1|4|0|Folge 4
    6. 1|5|0|Folge 5
    7. 1|6|0|Folge 6

    Für Serien verwende ich TheTVDB.

    Die Episodennamen für West of Liberty stehen hier: https://thetvdb.com/series/wes…iberty/seasons/official/1

    Die Episodennamen sich hier unschön, z.B. "Episode 1".


    Zur sicheren Erkennung der Episode also das S Feld in der info Datei ändern, z.B auf Episode 1


    Das habe ich jetzt mal in der info eingetragen, bekomme aber leider nach Neustart und dem scrapen immer noch bei jeder Episode die Folge 1 angezeigt.


    Das log zeigt Folgendes:



    Die "match"-Einträge wie hier beschrieben, kommen aber nicht.

    Muss ich erst noch die Datenbank oder die scraper-Dateien aus den Verzeichnissen löschen?


    Die info sieht jetzt so aus:


    Naja, der Sinn der SxxEyy-Nummerierung ist, daß die Sortierung nach Name der Reihenfolge entspricht, und fehlende oder doppelte Einträge unabhängig vom Aufnahmedatum sofort zu erkennen sind. War eines der "advanced"-Features von epgsearch und den uservars.

    Das möchte ich nicht wieder aufgeben ...


    Ich nummeriere bei Serien-Aufnahmen auch, allerdings nur mit 01_,02_...

    Es gibt einige Serien, da stört es den Scraper nicht, aber es gibt auch andere, da passt es gar nicht.

    Aber ob es an der Nummerierung liegt?



    Danke MarkusE für die Erklärung.


    Ich würde gerne meine Aufnahmen so anpassen, dass der Scraper die Aufnahme eindeutig erkennt.

    Denn den Scraper anzupassen, dass er alle Aufnahme immer fehlerfrei erkennt, halte ich für extrem aufwendig.

    Außer Du siehst Potential die Scraper-Ergebnisse zu verbessern, dann könnten wir, wie schon mal angedacht, die Fehler in einem anderen Thread sammeln.


    Kannst Du anhand von den Daten auf der TMDB-Website sagen, was im Pfad und der Info stehen müsste?


    z.B. von der Serie: West of Liberty


    Ich habe da schon mit dem Pfad und der info etwas experimentiert, aber keine durchweg richtige Erkennung der Serie hin bekommen.

    Die Serie habe ich mir aus der Mediathek geholt und versucht die info passend zu machen, damit Scraper auch die Episoden richtig erkennt.


    Pfad:

    Code
    1. vdr ~ # find /video/videos/_West_of_Liberty -name info
    2. /video/videos/_West_of_Liberty/West_of_Liberty_(1)/2019-10-29.12.27.3-1.rec/info
    3. /video/videos/_West_of_Liberty/West_of_Liberty_(6)/2019-10-29.15.02.3-1.rec/info
    4. /video/videos/_West_of_Liberty/West_of_Liberty_(5)/2019-10-29.15.02.3-1.rec/info
    5. /video/videos/_West_of_Liberty/West_of_Liberty_(4)/2019-10-29.13.51.3-1.rec/info
    6. /video/videos/_West_of_Liberty/West_of_Liberty_(3)/2019-10-29.13.38.3-1.rec/info
    7. /video/videos/_West_of_Liberty/West_of_Liberty_(2)/2019-10-29.12.48.3-1.rec/info

    info:


    Gruß und Danke

    Heiko

    Du könntest mal probieren, ob der VDR mit Patch jetzt nach dem ersten Tastendruck wartet, bis die Platte hochgefahren ist.

    Alles Andere wäre für mich im Moment Fleißarbeit.:)

    Gerne, aber noch mal konkret: Was soll ich wann und wie oft drücken?


    Mit Patch ist es jetzt so, dass ich ohne Unterbrechung scrollen kann und die Platte fährt während dessen hoch.

    Das Scrollen wird also nicht angehalten.


    Überhaupt, das Verhalten sieht für mich so aus, dass VDR einen Teil der Informationen bereit hält.

    Beim Scrollen kommt er auf ein Element/ Elemente, bei dem er etwas nachladen muss.


    Wenn die Platte einmal aufgeweckt wurde und ich schicke sie wieder in den Schlaf, kann ich die gesamte Liste (2600) in dem Verzeichnis durchscrollen ohne dass die Platte noch einmal geweckt wird. Gehe ich dann in ein Unterverzeichnis rein, wird die Platte wieder geweckt.

    Ich bin ja glücklich, dass ihr den Fehler korrigieren konntet. :)

    Auch wenn ich es nicht verstehe. :(

    Wenn VDR die c++ Objekte löscht, hätte es (mit meinem Patch) dafür eigentlich Einträge im Log geben müssen.

    Und wenn VDR die c++ Objeckte nicht löscht, dann ist das Sperren eigentlich nicht notwendig.

    Na ja, vieleicht habe ich ja etwas übersehen, oder VDR löscht die c++ Objekte an einer anderen Stelle ...


    Soll ich da noch einmal in die Spur gehen?

    Die Änderung habe ich vorerst hier im develop Branch commited:

    gitlab.com/kamel5/skindesigner


    Bitte testen. Wenn sich keine Auffälligkeiten ergeben, werde ich das dann im Oktober in den master Branch übernehmen.


    Läuft schon seit gestern Abend...


    Vielen Dank noch mal!


    edit:

    Ich sehe gerade,Du hast noch was dran gemacht?

    Das würde ich heute Abend noch einmal aktualisieren...


    Mit diesem Patch gibt es keinen Absturz mehr bei der Funktion "RecordingIsHD()".

    Wie erwartet, jedoch in der Funktion "RecordingIsUHD().


    bt:


    Also scheint der Patch das Problem zumindest in der Funktion "RecordingIsHD()" zu lösen.

    Wenn Du das dann testest, kannst Du bitte mal noch folgendes prüfen:

    Wenn im Aufzeichnungsmenü eine Aufnahme markiert ist und die Platte nicht läuft, mal mit der blauen Taste die Info-Seite aufrufen. Gibt es dann auch einen Absturz? Dabei werden die gleichen Funktionen benutzt.


    Erstmal hierzu:

    Nach der Kompilier-Orgie konnte ich die Abstürze wieder mit der beschrieben Vorgehensweise reproduzieren.

    - Platte in Standby,

    - Taste rot für Aufnahmemenü und Taste ok um in das Verzeichnis zu kommen an das die HDD gemountet ist,

    - Taste Down gedrückt halten,


    Der Absturz kommt nicht immer und wenn, dann bei verschiedenen Aufnahmen.

    Manchmal nach mehreren Versuchen, kann ich auch durch die gesamte Liste scrollen ohne Absturz.

    Dann muss ich den VDR neu starten oder rebooten.


    Beim Test mit der blauen Taste konnte ich keinen Absturz provozieren.

    Das heißt aber nicht, dass er auf diesem Weg nicht auftreten könnte.

    Hier entsteht ja nicht so viel "Stress" wie beim Scrollen durch die Aufnahme-Liste.


    Lediglich das OSD wird komplett schwarz bis die Platte hoch gelaufen ist und es wird die Info-Seite korrekt angezeigt.


    Mache ich, dauert nur ein wenig.


    Bezüglich der <optimized out> Meldungen im bt wollte ich mal wissen was da stehen würde und habe gemäß dem mal die Optimierungs-Flags von -O2 auf -O0 gesetzt.

    Damit konnte ich aber den Absturz nicht reproduzieren.


    Dabei ist mir aufgefallen, dass die Flags in meinem System nicht so gesetzt waren, wie ich es eigentlich wollte.

    Ich baue gerade mein System neu mit folgenden Flags:

    Code
    1. -march=native -O2 -pipe -ftree-vectorize -fomit-frame-pointer


    Ich hoffe, dass ich im Anschluss den Absturz reproduzieren kann um dann zu testen, ob Dein Patch hilft das Problem zu beseitigen.

    Im Notfall muss ich die relevanten Sachen mit den alten Flags noch mal bauen...


    Ich melde mich wenn ich neue Erkenntnisse habe.


    Vielen Dank und Gruß

    Heiko


    Ich habe beide Meldungen eingebaut.

    Bei einem Test, ohne tvscraper, der zum Absturz führte, sind diese Meldungen nicht im syslog aufgetreten.

    Beim Üben im Umgang mit esyslog habe ich in epg.c mal paar Meldungen eingebaut:



    Der bt wirft jetzt Folgendes raus:


    Das syslog spricht jetzt bis zum Crash Folgendes:



    Auffällig ist der Wert numComponents der völlig aus der Reihe tanzt.


    Das schaue ich mir als Nächstes mal an.

    Wenn Du selber kompilieren kannst, könntest Du mal folgendes probieren, in skindesigner coreengine/viewelement.c:

    Code
    1. bool RecordingIsHD(const cEvent* event, const tChannelID channelID) {
    2. // detect HD from 'info'
    3. bool isHD = false;
    4. int type = -1;
    5. return isHD; <--- das einfügen

    dann wird dieser Teil gar nicht benutzt, und schauen ob es dann auch abstürtzt.


    Dann fliegt er beim IsUHD-Test auf die Nase...



    Also da noch mal das selbe Spiel... und er fliegt beim isRadio auf die Nase...



    Nachdem ich isRadio auch deaktiviert habe, keinen Absturz mehr.

    Beim Scrollen dreht die Platte wieder hoch aber keine Probleme.


    Bei diesen Tests habe ich tvscraper als Plugin nicht geladen.


    Also kann man schon sagen, das diese Abstürze mit diesen Checks irgend wie zusammenhängen.