Kurzfristig ist das "24/7-mysql-Notebook" Blödsinn; immerhin waren die Aufwachzeiten bis vor kurzem voll ok.
Deine Entscheidung 
Beiträge von utiltiy
-
-
Hmmmm .... ich könnte mir also zB auf einem alten Notebook (vorhanden!) mysql und epgd installieren, die jetzige channelmap.conf raufkopieren und das Teil einfach 24/7 durchlaufen lassen. Auf dem yaVDR könnte ich dann epgd und mysql deinstallieren und müsste nur mehr scraper2vdr und epg2vdr auf dem yaVDR laufen lassen.
Stimmt das so?
Das stimmt so, dafür ist es eigentlich gedacht
-
2) Ist epgd & co darauf ausgelegt, auf einem 24/7 Server zu laufen?`Wenn ja: wie kann man ihnen das abgewöhnen?
Ja, ist es. Entweder damit zurecht kommen oder einen 24/7 Server einsetzen. Manches ist so wie es ist
-
Damit läuft es wieder durch, Danke
-
Der Patch funktioniert nicht mehr seit dem Patch von Klaus heute da es hier:
Überschneidungen gibt mit:
Alles anzeigenDiff- # Fixed locking the Channels list in cDisplayChannel, where the lock was still held
- # when Flush() was called (cont'd).
- #
- --- menu.c 2018/05/06 09:30:11 5.2
- +++ menu.c 2018/05/27 09:51:56 5.3
- @@ -4654,8 +4654,10 @@
- displayChannel = Skins.Current()->DisplayChannel(withInfo);
- positioner = NULL;
- channel = NULL;
- - LOCK_CHANNELS_READ;
- - channel = Channels->GetByNumber(cDevice::CurrentChannel());
- + {
- + LOCK_CHANNELS_READ;
- + channel = Channels->GetByNumber(cDevice::CurrentChannel());
- + }
- ProcessKey(FirstKey);
- }
-
xorg-server und xorg-server-common ebenfalls auf Ignore setzen, hatte ich auch
Die verwende ich:
- xorg-server-1.19.6+13+gd0d1a694f-2-x86_64.pkg.tar.xz
- xorg-server-common-1.19.6+13+gd0d1a694f-2-x86_64.pkg.tar.xz
-
Ich habe mit aktuellem Kernel und Nvidia immer noch das Problem mit den Farben im OSD und Menü.
Wenn ich den 4.14er Kernel nimm und den Nvidia 387.34 hab ich keine Probleme.
Ich habe SHD gegen ffmpeg 3.4.2 gebaut für den Test da ffmpeg 4.x in Arch einen Fehler beim kompilieren auswirft. SHD ist der Tree von pesintta (0.7.0_1_g3ed7840)
-
Ich hatte mit meinem NUC das Problem, er wollte nicht mit einem einfachen Kabel sondern eines mit 2.0. Hab auch erst geschaut weil ich dachte Kabel sei Kabel
-
Hast Du das HDMI Kabel mal gewechselt zum Test oder hat es eine 2.0 Spezifikation?
-
Der läuft durch, Danke
Das war der Fehler,zuvor:
Alles anzeigenCode- ==> Erstelle Paket: vdr-skinnopacity 1.1.3-5 (Fr 4. Mai 14:43:10 CEST 2018)
- ==> Prüfe Laufzeit-Abhängigkeiten...
- ==> Prüfe Buildtime-Abhängigkeiten...
- ==> Empfange Quellen...
- -> Aktualisiere das skin-nopacity git Repo...
- Fordere an von origin
- -> 50-skinnopacity.conf gefunden
- -> nopacity-always_show_displaychannel.diff gefunden
- -> vdr_2.3.3_compat.patch gefunden
- -> skinnopacity_vdr-2.3.5_compat.patch gefunden
- -> skinnopacity_vdr-2.3.8_compat.patch gefunden
- -> skinnopacity-timer.diff gefunden
- ==> Überprüfe source Dateien mit md5sums...
- skin-nopacity ... Übersprungen
- 50-skinnopacity.conf ... Durchgelaufen
- nopacity-always_show_displaychannel.diff ... Durchgelaufen
- vdr_2.3.3_compat.patch ... Durchgelaufen
- skinnopacity_vdr-2.3.5_compat.patch ... Durchgelaufen
- skinnopacity_vdr-2.3.8_compat.patch ... Durchgelaufen
- skinnopacity-timer.diff ... Durchgelaufen
- ==> Entferne existierendes $srcdir/ Verzeichnis...
- ==> Entpacke Quellen...
- -> Erstelle Arbeitskopie des skin-nopacity git Repos...
- Klone nach 'skin-nopacity' ...
- Fertig.
- Zu neuem Branch 'makepkg' gewechselt
- ==> Beginne prepare()...
- patching file displaychannel.c
- Hunk #1 FAILED at 90.
- Hunk #2 succeeded at 147 (offset -1 lines).
- 1 out of 2 hunks FAILED -- saving rejects to file displaychannel.c.rej
- patching file displaychannel.h
- patching file displaychannelview.c
- patching file displaychannelview.h
- ==> FEHLER: Ein Fehler geschah in prepare().
- Breche ab...
-
Mit diesem Patch (skinnopacity-timer.diff) baut er nicht unter Arch, habe die Patches drin:
- vdr_2.3.3_compat.patch
- skinnopacity_vdr-2.3.5_compat.patch
- skinnopacity_vdr-2.3.8_compat.patch
-
Alles anzeigenKann man das mit dem Bindestrich in den Griff bekommen bei Titeln?
Es kommt vor das im Namen nicht der erwartete - ist sondern einer der geringfügig länger und somit neue Verzeichnisse und Aufnahmen angelegt werden obwohl schon vorhanden....
Kann man da irgendwie eingreifen damit es eindeutig wird?
hier ein Beispiel, oben ist der Strich länger unten der "normale"
Ich habe immer noch das Problem mit dem Bindestrich kurz/lang im Namen der Serie
wie kann man da entgegenwirken?
-
Trotzdem bleibt die interessante Frage, warum ich keine Fehler bekomme.
Bei dir ist alles ein wenig anders, haben wir schon kürzlich festgestellt
-
Dein compat.patch ist nicht sauber. Zumindest funktioniert er nicht bei Arch... die beiden von fnu funktionieren und es lässt sich ein Paket bauen.
Vielleicht hilft dir die Info
-
-
Da hilft meist, auf die schnelle, es selber zu machen. Quellen findet man und zum wandeln kann man Inkscape nehmen, gibt es auch als Portable für Win falls nötig.
-
Hast Du das installiert zuvor?
-
Gibt es da nicht das epgd-get-id -[tvsp|tvm] dafür?
Geht problemlos zur Ermittlung
-
Hört sich nach Wunschkonzert an ...
-
Was soll uns das sagen?
Wer einmal seine channels.conf hat ändert im allgemeinen nur noch bei Veränderungen die erfahrungsgemäß eher selten vorkommen ...
