136
Entwicklung [ Development ] / Probleme mit Hama-mce Fernbedienung
« on: May 16, 2018, 16:39:50 »
Vielleicht hilft Dir das hier hier als workaround?
Show Posts
This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
137
Entwicklung [ Development ] / Fehler im RCU Plugin
« on: May 14, 2018, 21:41:57 »
Ich hab's selber geschafft!
Und ich habe Klaus Schmidinger gebeten, die Version mit der von ihm vorgeschlagenen Änderung auf seine Seite zu tun, damit folgende Builds (also hoffentlich auch MLD 5.4 und neuer) ebenfalls davon profitieren können.
Für die, die es interessiert:
Bis gestern hatte ich Die Anleitung für das Bauen der 5.4 ignoriert, weil ich ja für die 5.3 bauen wollte und mich auch nicht so recht an Docker ran getraut hatte.
Mehr zufällig also fand ich in der 5.4 Anleitung den Hinweis, was man für 5.3 tun soll (Anmerkung: dieser Hinweis sollte IMHO gleich ganz oben stehen und der Link im Wiki auch "5.3" beinhalten). In dem Hinweis ist übrigens ein Fehler drin: der -e Schalter beim echo fehlt.
Also eine neue VM angelegt, dies' Mal mit Debian stretch, und versucht die angegebenen Schritte durchzuführen. Irgendwas muss ich wohl gestern falsch gemacht haben, obwohl ich eigentlich hauptsächlich mit copy & paste gearbeitet habe. Jedenfalls wurden wieder die falsche VDR- und Kernelversion runtergeladen - mit dem erwarteten Effekt, dass mein erzeugtes rcu-Plugin nicht lief. Nach wiederum Stunden hatte ich keine Lust mehr, es war auch schon spät.
Heute wühlte ich erneut durch's Forum und fand zwei interessante Threads:
https://minidvblinux.de/forum/index.php/topic,8592.msg66050.html und
https://minidvblinux.de/forum/index.php/topic,8612.msg66196.html
Daraufhin löschte ich das Verzeichnis MLD in meinem Docker-Container und machte die ganze "Orgie" nochmal, langsam, besonders konzentriert und Schritt für Schritt - zunächst mit unverändertem rcu.c zwecks Test. Das erzeugte Binary hatte zwar auch eine geringfügig andere Größe als das Original (was mich bangen ließ), aber es funktionierte! Hurra, jetzt nur noch die o.g. kleine Code-Änderung einbauen und ein (hoffentlich) letztes Mal bangen...
Hä? Wieso war das Binary jetzt mehr als doppelt so groß? DAS war schnell gefunden: strip libvdr-rcu.so.2.2.0 wurde beim zweiten Mal make nicht ausgeführt, warum auch immer.
Falls Interesse besteht poste ich die "reparierte" Fassung vom RCU-Plugin als *.deb - vermute aber, mit dessen Benutzung stehe ich so ziemlich alleine da :-)
Und ich habe Klaus Schmidinger gebeten, die Version mit der von ihm vorgeschlagenen Änderung auf seine Seite zu tun, damit folgende Builds (also hoffentlich auch MLD 5.4 und neuer) ebenfalls davon profitieren können.
Für die, die es interessiert:
Bis gestern hatte ich Die Anleitung für das Bauen der 5.4 ignoriert, weil ich ja für die 5.3 bauen wollte und mich auch nicht so recht an Docker ran getraut hatte.
Mehr zufällig also fand ich in der 5.4 Anleitung den Hinweis, was man für 5.3 tun soll (Anmerkung: dieser Hinweis sollte IMHO gleich ganz oben stehen und der Link im Wiki auch "5.3" beinhalten). In dem Hinweis ist übrigens ein Fehler drin: der -e Schalter beim echo fehlt.
Also eine neue VM angelegt, dies' Mal mit Debian stretch, und versucht die angegebenen Schritte durchzuführen. Irgendwas muss ich wohl gestern falsch gemacht haben, obwohl ich eigentlich hauptsächlich mit copy & paste gearbeitet habe. Jedenfalls wurden wieder die falsche VDR- und Kernelversion runtergeladen - mit dem erwarteten Effekt, dass mein erzeugtes rcu-Plugin nicht lief. Nach wiederum Stunden hatte ich keine Lust mehr, es war auch schon spät.
Heute wühlte ich erneut durch's Forum und fand zwei interessante Threads:
https://minidvblinux.de/forum/index.php/topic,8592.msg66050.html und
https://minidvblinux.de/forum/index.php/topic,8612.msg66196.html
Daraufhin löschte ich das Verzeichnis MLD in meinem Docker-Container und machte die ganze "Orgie" nochmal, langsam, besonders konzentriert und Schritt für Schritt - zunächst mit unverändertem rcu.c zwecks Test. Das erzeugte Binary hatte zwar auch eine geringfügig andere Größe als das Original (was mich bangen ließ), aber es funktionierte! Hurra, jetzt nur noch die o.g. kleine Code-Änderung einbauen und ein (hoffentlich) letztes Mal bangen...
Hä? Wieso war das Binary jetzt mehr als doppelt so groß? DAS war schnell gefunden: strip libvdr-rcu.so.2.2.0 wurde beim zweiten Mal make nicht ausgeführt, warum auch immer.
Falls Interesse besteht poste ich die "reparierte" Fassung vom RCU-Plugin als *.deb - vermute aber, mit dessen Benutzung stehe ich so ziemlich alleine da :-)
138
Entwicklung [ Development ] / Fehler im RCU Plugin
« on: May 12, 2018, 20:23:33 »
'n Abend!
Nachdem ich heute den ganzen Tag damit verbracht habe, erstens nach http://www.minidvblinux.de/wiki/mld/entwicklung/402_entwicklungsumgebung die Entwicklungsumgebung einzurichten (Debian Jessie in einer VM und beim git clone habe ich git-5 statt git-4 benutzt) und zweitens Klaus' Vorschlag zu zu implementieren kann ich Teilerfolge melden.
Wie kann man eigentlich hier ein Wort verlinken? Die BBCode-Syntax mag das Forum offenbar nicht.
Es gab zwar diverse Fehlermeldungen z.B. fontconfig betreffend, aber die habe ich alle ignoriert, denn das RCU Plugin hat mit Fonts ja nichts zu tun. Durch Zufall habe ich bemerkt, dass vor dem Compilieren VDR 2.4.0 heruntergeladen wurde.
Der Teilerfolg ist, dass die erzeugte libvdr-rcu.so.2.4.0 auf meinen Test-VDR (der mit MLD 5.4 unstable läuft und sehr spartanisch eingerichtet ist) funktioniert wie sie soll, d.h. der Fehler nicht mehr auftritt. Schön.
Dann habe ich versucht, der Umgebung die Quellen von VDR 2.2.0 "unterzujubeln" indem ich selbige manuell 'runtergeladen und den Symlink (siehe unten) geändert habe. Das war anscheinend nicht genug: ich bekam zwar eine libvdr-rcu.so.2.2.0 erzeugt, aber mit der startet der VDR auf dem "Produktiv-System" (MLD 5.3 stable) nicht mehr. Nicht schön.
Im Verzeichnis ~/MLD/vdr/src/
vorher: vdr -> vdr-2.4.0
nachher: vdr -> vdr-2.2.0
Nun erneut der Ruf um Hilfe: wie komme ich zu einer lauffähigen libvdr-rcu.so.2.2.0 für MLD 5.3 stable? Vielleicht kann jemand mit mehr Erfahrung als ich dieses patch-File gebrauchen:
Eventuell wäre mir auch schon geholfen, wenn mir jemand erklärt wie ich das mit meiner Jessie-VM selbst hin kriege...
TIA
Matthias
Nachdem ich heute den ganzen Tag damit verbracht habe, erstens nach http://www.minidvblinux.de/wiki/mld/entwicklung/402_entwicklungsumgebung die Entwicklungsumgebung einzurichten (Debian Jessie in einer VM und beim git clone habe ich git-5 statt git-4 benutzt) und zweitens Klaus' Vorschlag zu zu implementieren kann ich Teilerfolge melden.
Wie kann man eigentlich hier ein Wort verlinken? Die BBCode-Syntax mag das Forum offenbar nicht.
Es gab zwar diverse Fehlermeldungen z.B. fontconfig betreffend, aber die habe ich alle ignoriert, denn das RCU Plugin hat mit Fonts ja nichts zu tun. Durch Zufall habe ich bemerkt, dass vor dem Compilieren VDR 2.4.0 heruntergeladen wurde.
Der Teilerfolg ist, dass die erzeugte libvdr-rcu.so.2.4.0 auf meinen Test-VDR (der mit MLD 5.4 unstable läuft und sehr spartanisch eingerichtet ist) funktioniert wie sie soll, d.h. der Fehler nicht mehr auftritt. Schön.
Dann habe ich versucht, der Umgebung die Quellen von VDR 2.2.0 "unterzujubeln" indem ich selbige manuell 'runtergeladen und den Symlink (siehe unten) geändert habe. Das war anscheinend nicht genug: ich bekam zwar eine libvdr-rcu.so.2.2.0 erzeugt, aber mit der startet der VDR auf dem "Produktiv-System" (MLD 5.3 stable) nicht mehr. Nicht schön.
Im Verzeichnis ~/MLD/vdr/src/
vorher: vdr -> vdr-2.4.0
nachher: vdr -> vdr-2.2.0
Nun erneut der Ruf um Hilfe: wie komme ich zu einer lauffähigen libvdr-rcu.so.2.2.0 für MLD 5.3 stable? Vielleicht kann jemand mit mehr Erfahrung als ich dieses patch-File gebrauchen:
Code: [Select]
--- rcu.c.orig 2015-02-17 14:13:00.000000000 +0100
+++ rcu.c 2018-05-12 19:12:55.060000000 +0200
@@ -362,5 +362,5 @@
void cRcuRemote::Recording(const cDevice *Device, const char *Name, const char *FileName, bool On)
{
- SetPoints(1 << Device->DeviceNumber(), Device->Receiving());
+ SetPoints(1 << Device->DeviceNumber(), On);
}
Eventuell wäre mir auch schon geholfen, wenn mir jemand erklärt wie ich das mit meiner Jessie-VM selbst hin kriege...
TIA
Matthias
139
Entwicklung [ Development ] / Fehler im RCU Plugin
« on: May 11, 2018, 16:43:52 »
Hallo mal wieder.
Vor Jahren habe ich mir das RCU-Plugin gewünscht, Ihr habt es netterweise ziemlich zügig zur Verfügung gestellt. Ich meine, "damals" lief es fehlerfrei, jetzt nicht mehr - und das ist mir lange nicht aufgefallen, weil ich immer nur nachts aufgenommen habe.
Den Fehler habe ich dem "VDR-Erfinder" Klaus geschrieben, und er meinte durch Ändern einer Zeile im Code von rcu.c sollte der Fehler behoben sein.
Würdet Ihr das bitte für mich mal einbauen? Ich benutze 5.3 stable und auf dem zweit-VDR 5.4 unstable.
Bin gespannt ob's hilft... (und werde natürlich berichten)
Vielen Dank im Voraus,
Matthias
Vor Jahren habe ich mir das RCU-Plugin gewünscht, Ihr habt es netterweise ziemlich zügig zur Verfügung gestellt. Ich meine, "damals" lief es fehlerfrei, jetzt nicht mehr - und das ist mir lange nicht aufgefallen, weil ich immer nur nachts aufgenommen habe.
Den Fehler habe ich dem "VDR-Erfinder" Klaus geschrieben, und er meinte durch Ändern einer Zeile im Code von rcu.c sollte der Fehler behoben sein.
Würdet Ihr das bitte für mich mal einbauen? Ich benutze 5.3 stable und auf dem zweit-VDR 5.4 unstable.
Code: [Select]
ersetze Zeile 364
SetPoints(1 << Device->DeviceNumber(), Device->Receiving());
durch
SetPoints(1 << Device->DeviceNumber(), On);
Bin gespannt ob's hilft... (und werde natürlich berichten)
Vielen Dank im Voraus,
Matthias
140
x86 Systeme (PC) / [GELÖST] Tastaturproblem
« on: May 06, 2018, 13:10:08 »
Unverhofft kommt oft.
Meinen Zufallsfund mit dem xdotool habe ich als neues Script /etc/X11/icewm/startup.d/numlock_on eingefügt:
Ob nun die Zeile mit rc.functions wirklich nötig ist sei mal dahin gestellt, es schadet aber offenbar auch nicht.
Endlich funktionieren die Ziffentasten meiner etwas exotischen Tastatur (Logilink 2.4GHz Kabellose Tastatur mit Mousepad).
Meinen Zufallsfund mit dem xdotool habe ich als neues Script /etc/X11/icewm/startup.d/numlock_on eingefügt:
Code: [Select]
#!/bin/sh
. /etc/init.d/rc.functions
/usr/bin/xdotool key Num_Lock
Ob nun die Zeile mit rc.functions wirklich nötig ist sei mal dahin gestellt, es schadet aber offenbar auch nicht.
Endlich funktionieren die Ziffentasten meiner etwas exotischen Tastatur (Logilink 2.4GHz Kabellose Tastatur mit Mousepad).
141
x86 Systeme (PC) / Tastaturproblem
« on: May 06, 2018, 12:31:17 »
Tagchen.
Inzwischen bin ich beim "Feintuning" meines VDR, derzeit bei der Tastatur und habe ein kleines Problem mit der remote.conf - nämlich funktionieren die Zifferntasten des Nummernblocks nicht. Die Tastatur bietet die Möglichkeit, das Ziffernfeld als Maus-Touchpad zu benutzen.
Wenn ich mittels Strg-Alt-F1 auf die Console wechsele, funktioniert der Nummernblock wie erwartet, d.h. es kommen Ziffern. Nach Umschalten auf Touchpad macht selbiges erwartungsgemäß nichts. Im X-Windows (VDR) jedoch ist es anders: Ich habe den Mauszeiger ausgeblendet, konnte aber über die "Windows-Taste" gefolgt von Cursor und Enter ein xterm starten. Dort ist zu sehen, dass der Nummernblock "nur" Cursortasten (und was da sonst noch ist, PgUp usw.) macht - also NumLock AUS ist. Eine dedizierte Numlock-Taste gibt es aber nicht, eine NumLock LED auch nicht.
Offenbar kennt die Tastatur DREI Betriebszustände: Touchpad (nur X), Cursortasten auf Nummernblock und Ziffern auf Nummernblock.
Leider kennt MLD kein xev, am Ubuntu-PC zeigt mir xev für die Zifferntasten KP_x mit x=0..9 - was ich auch erwartet hätte. Genau das habe ich in die remote.conf eingetragen, z.B.
XKeySym.0 0
XKeySym.0 KP_0
...
und natürlich VDR (und auch PC) neu gestartet. Die Plus-, Minus- und Enter-Taste des Nummernblocks funktionieren, die Ziffern nicht - was ja zu oben beschriebenem Verhalten (Cursor auf den Tasten - die habe ich aber NICHT in der remote.conf) passt.
Nun die Frage: Wie "zwinge" ich das X-Windows beim Start in den "NumLock ist AN" Modus? In grafischen Oberflächen gibt es dafür oft eine Einstellung. Auf einem anderen PC, der ebenfalls keine NumLock Taste hat, habe ich 'numlockx' installiert, das habe ich in MLD aber auch nicht. LXDE kennt eine Einstellung numlock=1 in /etc/lxdm/lxdm.conf - für icewm habe ich nichts finden können (außer an gefühlt 1000 Stellen den Hinweis, man möge 'numlockx' installieren).
EDIT:
Stundenlang habe ich "gegoogelt" und mein Posting NICHT abgeschickt. Ein paar Minuten nach dem Posten fand ich dann per Zufall, man möge
xdotool key Num_Lock
dafür benutzen. Das funktioniert auch, wenn ich es im xterm eingebe. Wo wäre eine geeignete Stelle, das automatisiert zu machen?
Inzwischen bin ich beim "Feintuning" meines VDR, derzeit bei der Tastatur und habe ein kleines Problem mit der remote.conf - nämlich funktionieren die Zifferntasten des Nummernblocks nicht. Die Tastatur bietet die Möglichkeit, das Ziffernfeld als Maus-Touchpad zu benutzen.
Wenn ich mittels Strg-Alt-F1 auf die Console wechsele, funktioniert der Nummernblock wie erwartet, d.h. es kommen Ziffern. Nach Umschalten auf Touchpad macht selbiges erwartungsgemäß nichts. Im X-Windows (VDR) jedoch ist es anders: Ich habe den Mauszeiger ausgeblendet, konnte aber über die "Windows-Taste" gefolgt von Cursor und Enter ein xterm starten. Dort ist zu sehen, dass der Nummernblock "nur" Cursortasten (und was da sonst noch ist, PgUp usw.) macht - also NumLock AUS ist. Eine dedizierte Numlock-Taste gibt es aber nicht, eine NumLock LED auch nicht.
Offenbar kennt die Tastatur DREI Betriebszustände: Touchpad (nur X), Cursortasten auf Nummernblock und Ziffern auf Nummernblock.
Leider kennt MLD kein xev, am Ubuntu-PC zeigt mir xev für die Zifferntasten KP_x mit x=0..9 - was ich auch erwartet hätte. Genau das habe ich in die remote.conf eingetragen, z.B.
XKeySym.0 0
XKeySym.0 KP_0
...
und natürlich VDR (und auch PC) neu gestartet. Die Plus-, Minus- und Enter-Taste des Nummernblocks funktionieren, die Ziffern nicht - was ja zu oben beschriebenem Verhalten (Cursor auf den Tasten - die habe ich aber NICHT in der remote.conf) passt.
Nun die Frage: Wie "zwinge" ich das X-Windows beim Start in den "NumLock ist AN" Modus? In grafischen Oberflächen gibt es dafür oft eine Einstellung. Auf einem anderen PC, der ebenfalls keine NumLock Taste hat, habe ich 'numlockx' installiert, das habe ich in MLD aber auch nicht. LXDE kennt eine Einstellung numlock=1 in /etc/lxdm/lxdm.conf - für icewm habe ich nichts finden können (außer an gefühlt 1000 Stellen den Hinweis, man möge 'numlockx' installieren).
EDIT:
Stundenlang habe ich "gegoogelt" und mein Posting NICHT abgeschickt. Ein paar Minuten nach dem Posten fand ich dann per Zufall, man möge
xdotool key Num_Lock
dafür benutzen. Das funktioniert auch, wenn ich es im xterm eingebe. Wo wäre eine geeignete Stelle, das automatisiert zu machen?
142
Allgemein [ General ] / extrecmenu "Kosmetik"
« on: May 03, 2018, 21:28:01 »
Hallo P3f,
Verschieben habe ich noch nie versucht, auch früher schon nicht. Mir geht's primär um (Um)Sortieren und ggf. Umbenennen.
{später}
Eine kurze Testaufzeichnung konnte ich sowohl Umbenennen als auch in ein neu angelegtes Verzeichnis verschieben. Dieses "DistributedVideoDirectory"-Plugin verstehe ich so, als dass zum einen mehrere Platten "einfacher" eingebunden werden können sollen und zum Anderen die Verschieberei irgendwie besser sein soll. Nun, für weitere interne Platten habe ich eh keinen Platz und 'ne USB-Platte daneben stellen finde ich doof. Das Verschieben hat ja mit der Testaufzeichnung geklappt, aber ich habe es bisher eigentlich nie gebraucht. OK, was man nicht kennt, vermisst man auch nicht :-)
Leider schreibt SHF im VDR-Portal auch (sinngemäß), dass Umbenennen etwas "risikobehaftet" sei. Auch die vermeintlich neue Version im Post #19 scheint ja nur einen Patch zur Behebung eines anderen Problems zu beinhalten. Vielleicht wird aus DistributedVideoDirectory mal ein MLD-Plugin in einer stable MLD-Version, das hätte speziell für mich (hoffentlich) den Vorteil, das "normale" Aufzeichnungsmenü verwenden zu können (weil da die Länge einer Aufzeichnung hübscher dargestellt wird, siehe oben).
Verschieben habe ich noch nie versucht, auch früher schon nicht. Mir geht's primär um (Um)Sortieren und ggf. Umbenennen.
{später}
Eine kurze Testaufzeichnung konnte ich sowohl Umbenennen als auch in ein neu angelegtes Verzeichnis verschieben. Dieses "DistributedVideoDirectory"-Plugin verstehe ich so, als dass zum einen mehrere Platten "einfacher" eingebunden werden können sollen und zum Anderen die Verschieberei irgendwie besser sein soll. Nun, für weitere interne Platten habe ich eh keinen Platz und 'ne USB-Platte daneben stellen finde ich doof. Das Verschieben hat ja mit der Testaufzeichnung geklappt, aber ich habe es bisher eigentlich nie gebraucht. OK, was man nicht kennt, vermisst man auch nicht :-)
Leider schreibt SHF im VDR-Portal auch (sinngemäß), dass Umbenennen etwas "risikobehaftet" sei. Auch die vermeintlich neue Version im Post #19 scheint ja nur einen Patch zur Behebung eines anderen Problems zu beinhalten. Vielleicht wird aus DistributedVideoDirectory mal ein MLD-Plugin in einer stable MLD-Version, das hätte speziell für mich (hoffentlich) den Vorteil, das "normale" Aufzeichnungsmenü verwenden zu können (weil da die Länge einer Aufzeichnung hübscher dargestellt wird, siehe oben).
143
Allgemein [ General ] / extrecmenu "Kosmetik"
« on: May 03, 2018, 09:40:33 »
Leider nein: im OSD-Menü ist nichts, im WebIf fand ich ebenfalls nichts. Im VDR-Wiki steht auf der Seite des Plugins auch nichts davon, dass das Format einstellbar wäre.
Im Quellcode des Plugins konnte ich mit meiner extrem bescheidenen Ahnung auch nichts finden; die Funktion bool cPluginExtrecmenu::ProcessArgs() macht nichts außer einem return NULL; - woraus ich interpretiere, dass es auch keine Plugin-Argumente kennt.
Ebenfalls habe ich nach langem Suchen im Quellcode gefunden, dass offenbar die Darstellungsweise mit dem ' für Minuten fest im Code verankert ist (ab Zeile 308 in mymenurecordings.c Version 1.2.5-git).
Schade. Jetzt muss ich mich quasi entscheiden, was mir wichtiger ist: die Möglichkeit zum Umbenennen und Umsortieren (also extrecmenu) oder eine "hübsche(re)" Darstellung der Aufzeichnungsdauer (also standard).
Im Quellcode des Plugins konnte ich mit meiner extrem bescheidenen Ahnung auch nichts finden; die Funktion bool cPluginExtrecmenu::ProcessArgs() macht nichts außer einem return NULL; - woraus ich interpretiere, dass es auch keine Plugin-Argumente kennt.
Ebenfalls habe ich nach langem Suchen im Quellcode gefunden, dass offenbar die Darstellungsweise mit dem ' für Minuten fest im Code verankert ist (ab Zeile 308 in mymenurecordings.c Version 1.2.5-git).
Schade. Jetzt muss ich mich quasi entscheiden, was mir wichtiger ist: die Möglichkeit zum Umbenennen und Umsortieren (also extrecmenu) oder eine "hübsche(re)" Darstellung der Aufzeichnungsdauer (also standard).
144
Allgemein [ General ] / extrecmenu "Kosmetik"
« on: May 02, 2018, 22:26:32 »
Heute mal eine "kosmetische" Frage von mir: das "normale" Aufzeichnungen-Menü zeigt ja die Dauer der Aufnahmen in Stunden und Minuten (h:mm) an. Leider macht das extrecmenu (bei mir, 5.3 stable) nicht, da stehen nur Minuten (mm')
Die Darstellung h:mm gefiele mir besser, kann man das irgendwo für extrecmenu einstellen? Ich habe nichts gefunden außer "Aufnahmelänge anzeigen ja/nein". Gibt es vielleicht ein Plugin-Argument?
Die Darstellung h:mm gefiele mir besser, kann man das irgendwo für extrecmenu einstellen? Ich habe nichts gefunden außer "Aufnahmelänge anzeigen ja/nein". Gibt es vielleicht ein Plugin-Argument?
145
Allgemein [ General ] / irgendwas kaputt gemacht?
« on: May 02, 2018, 21:59:48 »Die Meldung "Create a snapshot ..." kommt, weil vor dem zurückspielen des gewählten Snapshots, ein Snapshot des aktuellen Zustandes erstellt wird, nur für den Fall, dass man doch wieder auf den aktuellen Stand zurück möchte...Also doppelte Sicherheit sozusagen ;-)
Danke nochmal allen.
146
Allgemein [ General ] / irgendwas kaputt gemacht?
« on: May 01, 2018, 13:41:26 »Gehe ich richtig in der Annahme, dass er beim Reboot die eliminierten Libraries wiederholt?Cool! Offenbar ist alles wieder da!
Vielen vielen Dank für den Tipp mit den Snapshots.
147
Allgemein [ General ] / irgendwas kaputt gemacht?
« on: May 01, 2018, 13:28:55 »
Spannend, diese Funktion ist mir noch nie aufgefallen.
Ich fand unter Konfiguration - Snapshots ein Restore: -Dropdown. Da habe ich gewählt "auto snapshot before -y install smbclient" und Speichern geklickt. Da kommt "Create a snapshot of '/mnt/root/2018-05-01 12:34' in '/mnt/root/@root____________________'
You must reboot to activate the restore!
Dort irritiert mich ein bisschen das "create"...
Das mag daran liegen, dass ich diese Snapshot-Funktion gerade erst kennengelernt und noch absolut keine Ahnung davon habe.
Gehe ich richtig in der Annahme, dass er beim Reboot die eliminierten Libraries wiederholt?
Ich fand unter Konfiguration - Snapshots ein Restore: -Dropdown. Da habe ich gewählt "auto snapshot before -y install smbclient" und Speichern geklickt. Da kommt "Create a snapshot of '/mnt/root/2018-05-01 12:34' in '/mnt/root/@root____________________'
You must reboot to activate the restore!
Dort irritiert mich ein bisschen das "create"...
Das mag daran liegen, dass ich diese Snapshot-Funktion gerade erst kennengelernt und noch absolut keine Ahnung davon habe.
Gehe ich richtig in der Annahme, dass er beim Reboot die eliminierten Libraries wiederholt?
148
Allgemein [ General ] / irgendwas kaputt gemacht?
« on: May 01, 2018, 13:16:55 »
Macht er die von selbst und automatisch? ICH habe noch nie einen erstellt 
149
Allgemein [ General ] / irgendwas kaputt gemacht?
« on: May 01, 2018, 12:48:24 »
Hilfe!
Es geht um 5.3 stable.
Zu Testzwecken habe ich über's WebIf das Paket "smbclient" installiert, das hat ZWEI Pakete (libarchive13 und smbclient) geladen. Da es nicht das war was ich wollte habe ich das Kästchen smbclient im WebIf wieder ausgeschaltet um smbclient wieder zu deinstallieren - da wurden dann ZWÖLF Pakete gelöscht:
Uninstall smbclient
Removing smbclient
Removing pulseaudio
Removing bash
Removing libarchive13
Removing libgtk-3-0
Removing libatk-bridge2.0-0
Removing libatspi2.0-0
Removing libcairo-gobject2
Removing libepoxy0
Removing libltdl7
Removing liborc-0.4-0
Removing libspeexdsp1
Nun fürchte ich, das irgendwas dabei kaputt gegangen ist , habe aber keine Idee was. Ich hoffe, dass ich nach all der Arbeit von persönlichen Anpassungen (Menü usw.) nicht neu installieren muss...
Hilfe!
Es geht um 5.3 stable.
Zu Testzwecken habe ich über's WebIf das Paket "smbclient" installiert, das hat ZWEI Pakete (libarchive13 und smbclient) geladen. Da es nicht das war was ich wollte habe ich das Kästchen smbclient im WebIf wieder ausgeschaltet um smbclient wieder zu deinstallieren - da wurden dann ZWÖLF Pakete gelöscht:
Uninstall smbclient
Removing smbclient
Removing pulseaudio
Removing bash
Removing libarchive13
Removing libgtk-3-0
Removing libatk-bridge2.0-0
Removing libatspi2.0-0
Removing libcairo-gobject2
Removing libepoxy0
Removing libltdl7
Removing liborc-0.4-0
Removing libspeexdsp1
Nun fürchte ich, das irgendwas dabei kaputt gegangen ist , habe aber keine Idee was. Ich hoffe, dass ich nach all der Arbeit von persönlichen Anpassungen (Menü usw.) nicht neu installieren muss...
Hilfe!
150
Allgemein [ General ] / mount/umount USB (5.3 stable)
« on: April 21, 2018, 09:48:18 »
Zumindest das automatischen Einbinden bin ich durch Löschen (bzw. Verschieben) von /etc/udev/rules.d/11-usb-stick-auto-mount.rules los geworden. Das mit der /etc/vdr/commands.conf funktioniert auch wieder.
Vielleicht findet sich ja trotzdem ein sicher funktionierender Weg, einen USB-Datenträger automatisch zu mounten OHNE dass beim Rausziehen (im Fall FAT Dateisystem) das dirty-Bit gesetzt wird. Die mount Option 'ro' reicht offenbar nicht.
Also so 100%ig gelöst ist es noch nicht...
Vielleicht findet sich ja trotzdem ein sicher funktionierender Weg, einen USB-Datenträger automatisch zu mounten OHNE dass beim Rausziehen (im Fall FAT Dateisystem) das dirty-Bit gesetzt wird. Die mount Option 'ro' reicht offenbar nicht.
Also so 100%ig gelöst ist es noch nicht...