Produktive Problem- und Pluginlösungen für VDR 2.3.2 und höher

jasminj

Als Alternative laeuft hier vdradmin-am fehlerfrei mit VDR 2.3.2+ ...

Wenn channels scan aktiviert ist, n den Einstellungen auf 100 Sender oder so beschraenken.

Gruss
Frank

Zitat von fnu

Als Alternative laeuft hier vdradmin-am fehlerfrei mit VDR 2.3.2+ ...

Also die Bilder schauen ja ganz gut aus. Müsste ich mal probieren.

Aber bei mir zu Hause haben sich alle an das live WEB IF gewöhnt und so viel Arbeit ist es ned die Locks zu ersetzen.
Ich hab das ja in 1,5 Stunden hinbekommen, nur eben nicht mit besonders viel Grips. Bevor ich das jetzt mache wollte ich nur wissen, ob Lars was tut und wenn nicht, ob es ned g'scheiter ist mit dem original Stamm von 2015 (siehe letzter Post) zu werkeln und nicht mit der yaVDR Version von 2013, wie ich das jetzt gemacht habe.

Und mir ist auch nicht klar warum das live Plugin schlecht sein soll?
Würde mich wirklich interessieren, weil wenn es gute Gründe gibt es sterben zu lassen, wäre jetzt der richtige Zeitpunkt.

Auf der anderen Seite könnte es intern modernisiert werden und man könnte es auf lighttpd umstellen und andere Abhängigkeiten entfernen, aber wir sprechen hier von Locks die anders geworden sind und vielleicht von ein paar anderen Kleinigkeiten, die ich jetzt nicht sehe, aber der Großteil der SW wird passen und VDR ist im Inneren auch gleich geblieben. Wobei letzteres müsste ich mir in den Diffs von 2.0.0 auf 2.3.1/2.3.2 anschauen.

Und wenn mein Sohn Zeit hat, neben seinem Job und der Uni, dann kann er mir ev. beim Umstellen der HTML Seiten helfen, weil da geht das Abspielen mit VLC nicht mehr mit Chrom und Firefox. Mein Sohn kennt sich mit dem WEB Teufelszeugs nämlich viel besser aus und kann das sicher lösen. Er spricht immer von Restful API und WEB Applikationen (für ersteres gäbe es ein VDR Plugin).

LG,
Jasmin

Ich komm da aktuell nicht wirklich zu, ich hab in der Firma aktuell eine doofe Deadline, die ich dringend einhalten muss. Da wartet noch viel Arbeit...

Es darf also gerne jemand anders versuchen. Ich hatte es auch mal probiert, aber einfach nur die Locks setzen war's halt nicht. Da es jetzt eine genaue Vorschrift gibt, wann wie und in welcher Reihenfolge Locks zu setzen sind, muss meiner Meinung nach das ganz Ding daraufhin überarbeitet werden. Und dazu ist mir das (genau wie epgsearch) einfach zu komplex bzw. es fehlt die Zeit, den Code zu verstehen. Dann könnte ich gleich was neues schreiben...

Lars.

Hoi,

Wirbel hat damals eine erster versuch gemacht:
vdr-live @ vdr-2.3.1 ?

Das lauft einwandfrei bei mir, allerdings nur mit 'basic features'

Mit fr. gr Gr

Carel

Zitat von mini73

Da es jetzt eine genaue Vorschrift gibt, wann wie und in welcher Reihenfolge Locks zu setzen sind, muss meiner Meinung nach das ganz Ding daraufhin überarbeitet werden.

Gibt es diese "Vorschrift" irgendwo dokumentiert?

class cListBase {
...
  bool Lock(cStateKey &StateKey, bool Write = false, int TimeoutMs = 0) const;
       ///< Tries to get a lock on this list and returns true if successful.
       ///< By default a read lock is requested. Set Write to true to obtain
       ///< a write lock. If TimeoutMs is not zero, it waits for the given
       ///< number of milliseconds before giving up.
       ///< If you need to lock more than one list at the same time, make sure
       ///< you set TimeoutMs to a suitable value in all of the calls to
       ///< Lock(), and be prepared to handle situations where you do not get all
       ///< of the requested locks. In such cases you should release all the locks
       ///< you have obtained so far and try again. StateKey.TimedOut() tells you
       ///< whether the lock attempt failed due to a timeout or because the state
       ///< of the lock hasn't changed since the previous locking attempt.
       ///< To implicitly avoid deadlocks when locking more than one of the global
       ///< lists of VDR at the same time, make sure you always lock Timers, Channels,
       ///< Recordings and Schedules in this sequence.
       ///< You may keep pointers to objects in this list, even after releasing
       ///< the lock. However, you may only access such objects if you are
       ///< holding a proper lock again. If an object has been deleted from the list
       ///< while you did not hold a lock (for instance by an other thread), the
       ///< object will still be there, but no longer within this list (it is then
       ///< stored in the ListGarbageCollector). That way even if you access the object
       ///< after it has been deleted, you won't cause a segfault. You can call the
       ///< Contains() function to check whether an object you are holding a pointer
       ///< to is still in the list. Note that the garbage collector is purged when
       ///< the usual housekeeping is done.

Klaus

Hallo ,
kurze Frage , läuft rpihddevice auch mit dem 2.3.3 ?
Thanks
speed

Zitat von speed

kurze Frage , läuft rpihddevice auch mit dem 2.3.3 ?

Ja.

Zitat von jasminj

Bevor ich auf das live Plugin verzichte, verzichte ich lieber auf eine Update des VDR!

Und wer behauptet, dass vdradmin eine Alternative zu live sein soll, der kennt das live Plugin nicht!

3PO

Ich kenne beides gut, live und vdradmin-am, lauft beides bis heute bei mir. Insofern erlaube ich mir sehr wohl die Einschaetzung als Alternative.

Mir allerdings die Aussage in den Mund zu legen "live waere schlecht", ist schlicht unverschaemt!

Was soll ich aber sagen, live laeuft mit VDR 2.3.x nicht, vdradmin-am schon ... anstatt nun nur zu lamentieren, koennte man ja auch einfach losgehen und VDR 2.3.x erstmal mit vdradmin-am zu nutzen ...

Regards
fnu

hat sich erledigt

Zitat von 3PO

Bevor ich auf das live Plugin verzichte, verzichte ich lieber auf eine Update des VDR!

Musst du ja nicht
Es läuft bei mir mit diesem Patch. Und wenn ich meine Fragen aus dem Thread beantwortet bekomme, dann versuche ich vielleicht mir aus der Version von wirbel die sinnvollen Änderungen heraus zu operieren.

Überhaupt wäre ein Test des Patches von Nachteule durch andere hier sehr sinnvoll, weil dann wissen wir vielleicht endlich was nicht mehr geht und was gelöst gehört. Falls das jemand tut, bitte im andern Thread antworten.

LG,
Jasmin

Zitat von kls

Also gut, dann fangen wir mal an ;-).

Beiliegender Patch macht devstatus-0.4.1 (Source von hier) mit VDR 2.3.2 übersetzbar.
Ob es auch läuft sollte mal jemand testen, der das tatsächlich verwendet.

Klaus

Ich bin da gerade zufällig darüber gestolpert.

Mit vdr-2.3.3 lässt es sich bauen und wird auch im OSD angezeigt, nur SVDRP scheint nicht zu gehen:

vdr01_64 ~ # svdrpsend plug devstatus DEVSTAT
220 vdr01_64 SVDRP VideoDiskRecorder 2.3.3; Sun Apr  9 19:44:29 2017; UTF-8
900-DVB-Geräteliste:
900-  --- Gerät 1 ---:
900-    keine laufenden Aufnahmen
900-
900-  --- Gerät 2 ---:
900-    keine laufenden Aufnahmen
900-
900-  --- Gerät 3 (Gerät hat Dekoder, Primärgerät) ---:
900-    keine laufenden Aufnahmen
900-
900-  --- Gerät 4 ---:
900-    keine laufenden Aufnahmen
900-
900-  --- Gerät 5 ---:
900-    keine laufenden Aufnahmen
900-
900-  --- Gerät 6 ---:
900-    keine laufenden Aufnahmen
900-
900-  --- Gerät 7 ---:
900-    keine laufenden Aufnahmen
900-
900-  --- Gerät 8 ---:
900-    keine laufenden Aufnahmen
900
221 vdr01_64 closing connection
vdr01_64 ~ #

weiss jemand ob es für vdr-plugin-epgfixer einen patch gibt ? (google + board suche sagt nein)

ansonsten scheint ja erstmal alles zu gehen was wir als Distribution so brauchen (das hätte ich vor einem Jahr nicht gedacht )

Was ist mit live?
Wird es dann in LE9 erstmal rausfliegen?

Was bitte ist LE9?

Der Nachfolger von LE8.

Libreelec

Zitat von tecfreak

Wird es dann in LE9 erstmal rausfliegen?

im Augenblick kompiliert erstmal alles (alles an Patches eingebaut was so herumschwirrt für 2.3.x) bis auf epgfixer - ob das dann auch alle so funktioniert weiß ich auch noch nicht

Sind ein bisschen in Zugzwang da VDR 2.2 mit UHD wohl nicht so fehlerfrei klar kommt und VDR 2.3.x das angeblich fixt (ich kann das nicht nachstellen) zumindest für AML und Intel.
Durch unser eher ungewöhnliches Setup wäre der Verlust von 50% der Plugins problematisch gewesen (eigentlich war das schon für LE8 geplant) aber die Situation hat sich ja gebessert durch die vielen Freiwilligen hier