- Jeder Nutzer muss den zusätzlichen Parameter im Setup selbst an der richtigen Stelle ergänzen (fehleranfällig) oder die Defaults mit dem zusätzlichen Parameter neu laden (kann übersehen werden).
Da ich euch beiden zustimmen kann ein Vorschlag meinerseits: prüfen beim Start des Plugins ob " -re " in den Parametern enthalten ist. Falls nein, an der richtigen Stelle ergänzen.
Man könnte es über umask machen, zur Vereinfachung wäre es super, wenn vdr die Datei bei Bedarf mit den richtigen permissions anlegt. Etwa so in der Art:
--- tools.c.orig 2024-09-07 17:54:32.728622969 +0200
+++ tools.c 2024-09-07 18:01:29.332622969 +0200
@@ -716,8 +716,18 @@
void TouchFile(const char *FileName)
{
- if (utime(FileName, NULL) == -1 && errno != ENOENT)
- LOG_ERROR_STR(FileName);
+ if (utime(FileName, NULL) == -1)
+ if (errno == ENOENT) {
+ int fd = creat(FileName);
+ if (fd != -1) {
+ fchmod(fd, 0666);
+ close(fd);
+ }
+ else
+ LOG_ERROR_STR(FileName);
+ }
+ else
+ LOG_ERROR_STR(FileName);
}
time_t LastModifiedTime(const char *FileName)LibreELEC nutzt keine libmali sondern vernünftigerweise mesa. Die libmali muss außerdem immer zum Kerneldevice kompatibel sein. Die kannst du nicht nach Belieben mischen. Gibt es eine libGLESv2.so.* ?
Ja, gibt es:
/usr/lib/aarch64-linux-gnu/libGLESv2.so
/usr/lib/aarch64-linux-gnu/libGLESv2.so.2
/usr/lib/aarch64-linux-gnu/libGLESv2.so.2.1.0Du meinst alternativ mit softhddevice-drm-gles versuchen? Wäre schade, da softhdodroid unter 20.04 wirklich stabil lief.
Ja das ist mir schon bekannt. Nur leider kann ich mangels Hardware nicht mit dem Kernel 5.4 testen.
Ich habe hier nur Odroid-N2+ und wie du schon sagst, da läuft es mit Kernel 4.9 und 5.15. Wobei der Kernel 5.15 eh noch nicht für produktiven Einsatz geeignet ist. Da hat Dr. Seltsam schon recht ein SK1 würde da sicher helfen
Ich hatte gestern festgestellt, dass Hardkernel zwar nicht auf ihrer Übersichtsseite, wohl aber auf dem Downloadserver eine Ubuntu 24.04-Version hat. Darin ist ein Kernel 6.6.44-118 enthalten. Beim Bauen von softhdodroid erhalte ich
/usr/bin/ld: cannot find -lMali: No such file or directory
/usr/bin/ld: cannot find -lavfilter: No such file or directoryKomischerweise gibt es libavfilter, warum er es nicht findet muss ich noch verstehen. Aber eine libMali gibt es definitiv im Gegensatz zu 20.04 (nutze ich bisher) nicht. LibreElec ist auch bei Kernel 6.6.x - werde nachher mal versuchen die libMali daraus zu nehmen. Oder gibt es eine einfachere Möglichkeit an eine passende libMali zu kommen? Hat bereits jemand erfolgreich (/-los) mit dem Ubuntu 24.04 basierendem Image softhdodroid ans Laufen gebracht?
Jetzt habe ich den use-case verstanden: Workaround für Fehler in VDR.
Ist aber inzwischen nicht mehr notwendig, der Fehler ist in vdr-2.6.8 mit "The EIT scanner now checks whether there is a proper device before adding a channel to the scan list." behoben. Damit funktioniert der EIT Scanner auch, wenn ein IPTV Kanal innerhalb der Kanäle, über die der EIT Scanner läuft, liegt. Der EIT Scanner ignoriert seit vdr-2.6.8 diesen Kanal. Siehe auch RE: [Patch] Unbenutzte Frontends schließen
Könnte sein. Auf dem Server läuft noch 2.6.7. schaue ich mir an. Nichtsdestotrotz finde ich es eleganter, die Favoriten in live per Kanalgruppe und nicht per Kanalnummern zu definieren. Sonst muss die Liste jedes Mal nachgearbeitet werden, sobald man die Favoriten ändert (einmal im VDR - unerlässlich, aber auch einmal zusätzlich in live).
> Wenn ich nun meine IPTV Kanäle ausklammern will, müssen die nach der EPG Grenze kommen.
Verstehe ich nicht. Das IPTV Plugin teilt doch dem VDR mit, dass die IPTV Kanäle kein EPG haben. Das müsste VDR doch berücksichtigen (?).
Zumindest hatte ich anfangs Probleme damit und seit VDR 2.6.7 mit der Max-Funktion / der Umstellung der Kanalliste nicht mehr. Kann mir mal bei Gelegenheit den Codeteil anschauen, der den EPG Scan unterdrücken sollte.
Wenn ich mir den Startbeitrag des Threads ansehe, frage ich mich außerdem, ob die Kanalgruppen für die Zeitleiste das nicht schon in ähnlicher Weise erfüllen. Eventuell müsste man diese nur auf die anderen Programmübersichten anwenden?
Korrekt, die Funktionalität ist ähnlich. Nur muss ich in live bei der Definition der Kanlgruppen mit Kanalnummern arbeiten, durch meinen Patch habe ich schlicht 3 channels.conf-Kanalgruppen drin. Ändere ich meine Kanalliste und füge einen Favoriten hinzu/lösche einen raus muss ich nichts anpassen. In der aktuellen iptv Implementierung aber schon.
Eine andere Möglichkeit wäre, die Definition der iptv Favoriten-Kanalgruppen (bei mir derzeit per favoritegroups.cfg) in die vorhandene Einstellung bei iptv zu integrieren. Ist aber am Ende dann nur Geschmacksache, ob ich eine zusätzliche Konfigurationsdatei haben will oder in der bestehenden GUI die Einstellung mache. Das filtern per channels.conf Kanalgruppen ist für mich persönlich alternativlos.
Ich sehe noch nicht so richtig den Mehrwert von diesem Patch. Also, in der Zeit, die ich brauche, um die relevanten Kanalgruppen in favoritegroups.cfg einzutragen, den richtigen Ort für favoritegroups.cfg zu finden und favoritegroups.cfg dort zu speichern, habe ich doch die channels.conf schon 3 mal umsortiert.
Oder übersehe ich hier etwas? Gibt es einen Grund, im VDR selbst andere Kanäle vorne haben zu wollen als in live?
~ Markus
Ganz einfach: momentan gibt es im VDR nur die Möglichkeit, den EPG Scan bis zu einer maximalen Kanalnummer durchzuführen. Wenn ich nun meine IPTV Kanäle ausklammern will, müssen die nach der EPG Grenze kommen. Da ich für einige IPTV Kanäle EPG über DVB-S besorgen muss, müssen diese Dummy-Kanäle vor der EPG Grenze kommen. Nun ergibt sich das Bild in der Kanalliste
Block von Favoritenkanäle
Dummy-Kanäle
IPTV Kanäle
sonstige von EPG auszuklammernde Kanäle
am Ende Sammelsurium der neu gefundenen DVB-S Kanäle
Mich störte daran, dass ich immer über die Dummy-Kanäle hinweg zappen muss, um zu meinen weiteren "Favoriten" wie z.B. iptv-Kanäle zu kommen.
Das ist für mich der konkrete Anwendungsfall.
Ich bin aber auch schon am überlegen (siehe separaten Thread Link) mir einen ähnlichen Mechanismus für den EPG Scan zu überlegen. Dann würde es keinen EPG Max-Kanal mehr geben, sondern eben eine Liste an Kanalgruppen, die beim EPG-Scan berücksichtigt werden sollen. Ich meine eine Idee zu haben wie es funktionieren könnte, dann würde ein Grund für den iptv Patch wegfallen. Wobei ich es ehrlich gesagt gut finde, in iptv die Möglichkeit zu haben, bestimmte Kanalgruppen auszuschliessen, ohne dass ich in channels.conf Limitierungen beachten muss.
Mag aber alles persönliche Vorliebe sein... 
Da ich beim Erweitern des live-Plugins die Kanalgruppen nutze, um Favoritenkanäle zu definieren, würde ich das gerne auch auf den EPG-Scanner anwenden.
Warum: wie in einigen Diskussionen im Forum schon besprochen, gibt es Kanäle, die man beim EPG ausklammern möchte (z.B. in meinem Fall iptv-Kanäle). Nun mache ich das aktuell mit der VDR-Einstellung "Setup.EPGScanMaxChannel" und schiebe meine iptv-Kanäle auf höhere Nummern. Funktioniert auch prinzipiell, aber damit muss ich meine channels.conf in eine Reihenfolge bringen, dass alle EPG-relevanten Kanäle vor den iptv Kanälen kommen. Nun würde ich gerne die Reihenfolge in der channels.conf nach eigenem Wunsch und unabhängig von EPG ja/nein festlegen.
Frage: gibt es eine einfache Möglichkeit, zu einem Kanal (z.B. Kanalnummer oder Kanal ID) die dazugehörige Kanalgruppe herauszufinden? Meine "stupide" Idee wäre es, von der Kanalnummer solange zu dekrementieren, bis ich auf die dazugehörige Kanalgruppe stosse.
Hmja, auch wieder wahr
Wäre es dann denkbar, zumindest dasselbe Format zu verwenden? Dann könnte man eine bestehende epgsearchchangrps.conf einfach rüber linken.
Machbar, wobei mir das aufwändiger zum Konfigurieren erscheint. In meinem Fall muss ich nur 3 Kanalgruppen aus der channels.conf angeben und habe meine Favoriten. Bei der epgsearchchangrps.conf definiert man die Gruppen neu indem man einen Namen + die dazugehörigen Kanal-Ids angibt. Kann man machen. Wäre es doch nicht besser auch in epgsearch mit den Kanalgruppen aus channels.conf zu arbeiten oder verstehe ich noch nicht den Nutzen der epgsearchchangrps.conf?
Wie gesagt, nutze epgsearch nicht und kann es deshalb (noch) nicht nachvollziehen.
Anbei die v2 des Skripts. Nun kann man wie von Stefan gewünscht die Anzeige der Favoritenkanäle durch den Patch in den Einstellungen von live ein-/ausschalten plus kleinere Korrekturen. Aufgrund der PO-Dateien wurde der Patch nun etwas größer...
Feedback wie immer gerne.
Hm, so etwas gibt es in epgsearch ja schon mit der epgsearchchangrps.conf.
Ist das echt sinnig, das nochmals zu bauen?
Sinnhaft, solange man wie ich kein epgsearch benutzt. 
kls : bitte die Datei mit permission 666 anlegen lassen, damit es keine Zugriffsprobleme gibt. Wäre auch gut bei der ".sort".
Hintergrund: z.B. bei softhdodroid muss der vdr als root laufen und in meinem Fall wurde dann die .sort mit 644 und somit nur für root schreibend angelegt.
Ich habe heute eine erste Umsetzung der Favoritenkanäle in live gemacht. Anbei der Patch.
Wie funktioniert es: man legt im live-Plugin Konfigurationsverzeichnis eine Datei favoritegroups.cfg an und trägt dort pro Zeile eine Kanalgruppe ein, die angezeigt werden soll. Beispiel basierend auf Klaus's Standard-channels.conf:
ARD und ZDF
Dritte Programme
NachrichtenNach einem Neustart vom VDR zeigt live im Menü "Was läuft", "Programm" und "Zeitleiste" nur noch die Programme an, die in den o.g. Kanalgruppen sind. Funktioniert soweit prima.
Info: damit bei Zeitleiste nur meine Favoritenkanäle angezeigt werden, habe ich das Laden der Einstellung "Kanalgruppen für die Zeitleiste:" deaktiviert. So liest er beim Start einmalig die Favortienkanäle ein und ab da könnte man bis zum nächsten Neustart in der genannten Einstellung händisch Kanäle aufnehmen. Wird aber beim nächsten Start wieder überschrieben.
Todo: abgesehen von etas Code-Cleanup, dem Handling der Einstellung "Kanalgruppen für die Zeitleiste:" werde ich vermutlich noch das Verhalten bei leerer Konfigurationsdatei anpassen (momentan bedeutet leere/nicht vorhandene Konfiguration überhaupt keine Kanalanzeige.
Gerne Feedback geben, eventuell kann der Patch so oder so ähnlich in Live einfliessen.
Sorry für die späte Rückmeldung, kam erst jetzt dazu. Testaufbau:
Tests:
1. Timer programmiert via Live auf dem VDR Server. VDR Server nimmt auf, Aufnahme ist sichtbar in der Live Aufnahmeübersicht, Clients sehen die neue Aufnahme nicht (erklärbar, da .update fehlt und diese nicht bei Bedarf angelegt wird; kein Triggern von UPDR)
2. Änderungen aus dem diff von dir am VDR Server händisch übernommen (aufgrund des Versionssprungs passte der diff nicht mehr ganz). VDR am Server neu gestartet. Beide Clients haben direkt auf den discover-Broadcast reagiert und sich somit registriert. Eine Aufnahme programmiert. Aufnahme taucht bei beiden auf.
3. 4 Aufnahmen mit gleichem Startzeitpunkt programmiert. Auf beiden Clients wurde 4 Mal der video directory scanner thread gestartet und beendet. Aufnahmen waren bei beiden Clients sichtbar.
Ergebnis: grundsätzlich funktioniert der UPDR Broadcast. Zwei Fehlerfälle könnte ich mir aber vorstellen:
Auch ohne die Antwort auf die 2 Fehlerfälle spricht doch dennoch nichts gegen die Aufnahme des Broadcast-Befehls, oder? Eventuell müsste man den ersten Fehlerfall noch prüfen und u.U. ein Neueinlesen starten oder den Request schedulen. Neueinlesen starten ist vermutlich die einfachere Umsetzung.
Ich lasse bei mir den Broadcast-Patch mal drin und werde weiter beobachten. Wobei mehr "Stress" als 4 Aufnahmen parallel kann ich mir nicht vorstellen...
Ich habe keinen Scrapper und bei mir findet Live die vorhandenen Aufnahmen in der Programm Übersicht und in den Suchergebnissen.
Was ist anders bei mir (oder dir) ?
Was ich aber in dem Zusammenhang vermisse, wäre, dass ein vorhandener Timer (natürlich zu einem anderen Zeitpunkt, sonst wird er ja als aktiver Timer angezeigt) auch in den Suchergebnissen angezeigt werden würde. Das verhindert versehentlich doppelte Timer zur gleichen Sendung.
Bei mir (ungepatcht und ohne TVScraper) werden vorhandene Aufnahmen auch gefunden. Fände die Timer-Erweiterung auch praktisch.
Die Funktion BroadcastSVDRPCommand() gibt es aber noch, die könnte mrjoe direkt verwenden. Wobei sein Ansatz nur beim Start einer Aufnahme greift. Wenn dies aber parallel zu .update wirken soll, wäre wohl die TouchUpdate() Funktion der zentralere Ort.
Leider weiß ich nicht mehr, wie sich das mit dem "too fast" ausgewirkt hat. Das müsste mal jemand untersuchen, bevor wir das wieder einbauen.
Du meinst das
BroadcastSVDRPCommand("UPDR");in die Funktion cRecordings::TouchUpdate(void) einzubauen? Kann ich gerne machen und testen.
Nachdem ich mehr&mehr mit live meine Timer programmiere würde ich mir wünschen, dass ich eine Favoriten-Kanalliste einschalten könnte, sodass bei
nur meine Favoritenkanäle angezeigt werden. Ist das mit Boardmitteln möglich bzw. falls nicht, gibt es hierfür Interesse? Falls letzteres würde ich mir mal einen geeigneten Patch überlegen.
Ok, dann ist die Funktion as intended - man sollte nur (was ich nicht gemacht habe) zuvor eine .update anlegen. Dann greift der Mechanismus, benötige kein recordings-script und ich kann auf den Patch verzichten. 
Wenn eine Aufnahme startet wird .update getoucht, was bei allen Clients, die das gleiche Video-Directory benutzen, zum Update führt.
Habe es nochmals ohne Patch getestet. Das "touchen" von .update macht vdr (bei mir 2.6.7) nur, wenn bereits eine .update existiert. --> ohne eine existierende .update triggert vdr selbst auch kein "touch". Ist das so gewollt?
Verständnisfrage: wird durch das "touchen" durch den VDR Server beim Start der Aufnahme das Aufnahmeverzeichnis durch den Server ebenfalls komplett neu eingelesen?