179 replies to this topic

[anudanan]

Da bin ich mal gespannt, insbesondere ob die beiden USB  HDDs dann immer richtig gemountet werden, wenn du keine UUID nutzt und Receiver 1 neu startest.

 

Openpli kann auch noch mit Labels der HDDs umgehen und mountet diese dann passend auf /media/labelname, aber wenn die keine Labels haben, landen die HDDs nicht immer an der gleichen Stelle, weshalb UUID ja hilft. 

Ich habe in meiner /etc/fstab immer die UUID genutzt. Labels würden aber auch gehen, dann muss man die fstab nicht ändern, Ich habe aber keine Ahnung, wie  man mit der GUI das Label auf die HDD bekommt. Habe noch nie mit den Labels gearbeitet.

 

Auf der linux CLI kann man das Label mit

 

e2label /dev/sdx1 Label

setzen, wobei dann das x durch a, b, c ersetzt werden muss, je nach dem ,welche HDD

 

ohne Label und ohne UUID landen die glaube ich auf /media/sdb1 oder /media/sdc1 aber nicht immer gleich herum

Edited by anudanan, 1 April 2020 - 15:50.

[Kredar]

Label damit meinst Beschriften? Das geht im Freigabemanager. Das eine Bild was ich heute gepostet habe zeigt es "USB 1 HD" bei mir. Kann man dort per Fernbedienung eingeben.

Ich werde es testen, und hier das Ergebnis schreiben nach ein paar Neustarts wenn es an Receiver 2 klappt ob die Platten immer da sind.

Wenn das so einfach geht wie erwähnt, dann ist das echt easy und in 10 min. erledigt dann ganze pro Receiver.

mfg

Edited by Kredar, 1 April 2020 - 16:19.

[anudanan]

Der Freigabemanager unter den Netzwerkeinstellungen vergibt keine Labels für lokale eigene HDDs

Der vergibt nur die Namen für das Verzeichnis unter /media/net wohin die Netzwerkfreigabe gemountet wird

Edited by anudanan, 1 April 2020 - 16:28.

[Kredar]

Ne diese muss man per Hand ändern. Stehen bestimmt auch irgendwo. Das sollte aber kein Problem sein. Schlimm wäre es wenn man es per Hand ändert, und danach sind die weg weil man die Datei editiert hat .

mfg

[anudanan]

Die Antwort habe ich jetzt nicht verstanden. Was meinst du genau?

[Kredar]

Dein Label von der internen Platte. Das muss man von Hand ändern. Zumindest glaub ich dass, muss ich später Mal schauen.

mfg

[anudanan]

Ja, das denke ich auch, dass man das von Hand machen muss. Wenn man dann einmal mit 

e2label

 

Das Label der HDD gesetzt hat, sollte die immer passend gemountet werden, also so wie mit der UUID, nur dass man dann mit openpli nie mehr die fstab ändern muss, wenn einmal das Label auf die HDD gebracht wurde. Ein UUID Eintrag überstimmt aber glaube ich das Mounten mit dem Labelnamen

[Kredar]

So habe eben beide Receiver per USB-Stick komplett neu Installiert. Die Freigaben habe ich nur per GUI gemacht, nichts editiert oder so. Und was soll ich sagen, gefunden wurden beide USB-Platten auch am PC zugriff ging auch ohne was am Receiver 1 (mit den USB-Platten) zu ändern. Am Receiver 1 (mit den USB-Platten) habe ich nichts Freigegeben, oder im Netzwerk (außer der festen IP) irgendwas eingestellt/verstellt. Am Receiver 2 (den ohne USB-Platten), habe ich per Netzwerkbrowser die beiden USB-Platten plus die interne Platte von Receiver 1 problemlos einbinden können und kann auch drauf zugreifen.

 

Nun aber wieder mal: Wenn man am Receiver 2 einen neustart macht, sind die /media/net - Verbindungen/Freigaben weg. Erst wenn man "Erneut Verbinden" im Netzwerk-Menü drückt ist alles da bis zum Neustart.

 

Ich kann sagen das ist ein Bug, sorry. Was soll ich nun noch Falsch gemacht haben? Ich habe alle komplett neu Aufgesetzt/Installiert ohne das ich irgend eine Config per Hand geändert/kopiert habe auf einen der beiden Receiver.

 

Da sollte mal ein Dev genau hinschauen, das Automount von Receiver 2 wird beim Neustart schlichtweg nicht gelesen oder ignoriert. Außer es gibt noch eine Einstellung was das Automount.xml automatisch einlesen lässt in der GUI im Expertenmodus. Das hätte ich aber noch nicht gefunden...

 

mfg

Edited by Kredar, 2 April 2020 - 10:20.

[anudanan]

Gut zu wissen, dass openpli die ganzen samba Freigabe selber einträgt

 

Als was wurden deine USB HDDs im Receiver 1 genau unter /media gemountet?

Wenn die kein Label haben, vermute ich sdb1 und sdc1 oder andere vom System vergebene Namen,

 

Wenn das so ist, dann kann es sein, wenn du Receiver 1 mal neu startest, dass die HDDs anders herum gemountet werden. Wenn du eine feste Zuordnung des Namens der Verzeichnisses unter /media mit der HDD haben willst, dann solltest du noch die Labels vergeben oder die UUIDs wieder verwenden.

 

Dass das Problem mit diesen ganzen Versuchen nicht gelöst ist, hatte ich ja schon vermutet. Kann ja nur an dem openpli 7.2  auf Receiver 2 liegen,

 

Gut, dass ich jetzt keinen Besen fressen muss.

 

Es werden also beim Start von Receiver 2 die in der automount.xml Datei hinterlegten Netzwerkmounts nicht automatisch verarbeitet.

Wie du schon geschrieben hast, tut das bei openpli 4.0. Es tut aber auch bei openpli 7.0 immer noch, da ich 7.0 auf zwei Boxen haben, kann ist das bestätigen

 

Da muss also irgendwo etwas in Richtung 7.2 kaputt gegangen sein.

[WanWizard]

Wenn es reproduziert werden kann (keine Bereitstellung auf Empfänger 2 nach einem (Neu-) Start), sollte es im Debuglog sichtbar sein, nachdem die Debug-Ebene in /usr/bin/enigma2.sh von 3 auf 4 geändert wurde.

Ist das der Fall?

[anudanan]

Das Problem hatte er hier vor der letzten Neuinstallation auf dem Receiver 2 schonmal im Debug Level 4 gelogged

 

https://forums.openp...dpost&p=1183520

 

 

In dem Trace sieht man keinen output vom Automount, wo er nach dem Neustart der Box etwa tut. Man sieht gar keine automount output, so als ob AutoMount.py gar nicht aufgerufen wird beim Neustart.  Wielleicht kannst du erkennen, wo der automount hätte erscheinen müssen.

Edited by anudanan, 2 April 2020 - 13:38.

[WanWizard]

Entschuldigung, das habe ich nicht gesehen.

Ich vermisse viel mehr in diesem Debuglog, zum Beispiel:

[Console] finished: ('/bin/ping', '/bin/ping', '-c', '1', 'www.google.nl')
[Console] finished: ('/bin/ping', '/bin/ping', '-c', '1', 'www.google.com')
[Console] finished: ('/bin/ping', '/bin/ping', '-c', '1', 'www.openpli.org')

Was deutet darauf hin, dass das Netzwerk zu diesem Zeitpunkt noch nicht aktiv ist?

[anudanan]

Das wäre eine Idee

@kredar
Wie kommt dein Netzwerk genau in die Gänge und wie ist die Box im Netzwerk eingebunden?
Lan, wlan mit dhcp usw?

Edited by anudanan, 2 April 2020 - 16:13.

[WanWizard]

Kein dhcp:

read configured interface: {'lo': {'dhcp': False}, 'eth0': {'dhcp': False, 'netmask': [255, 255, 255, 0], 'gateway': [192, 168, 0, 1], 'address': [192, 168, 0, 13]}}

Das Problem könnte eine Verzögerung bei der Verbindung sein. Ich habe bereits erwähnt, dass ich ähnliche Probleme mit Leuten gesehen habe, die Fritzboxen verwenden (von denen ich glaube, dass sie in Deutschland beliebt sind?).

 

( google translate )

[anudanan]

Man könnte für einen ersten Test einfach mal ein sleep von 30 Sekunden in das enigma2.sh einbauen, um zu sehen, ob es dann gehen würde .
Könnte das helfen?
Fritzboxen sind sehr beliebt in Deutschland

Edited by anudanan, 2 April 2020 - 16:15.

[Kredar]

Keine Fritzbox, feste IP und 1000mbit Lan- Kabel (beide Receiver). Wie gesagt über OpenPli 4 ging alles einwandfrei mit den selben Netzwerk. Also am Netzwerk liegt es nicht, sind eh am einen LAN-Switch (Router ist davor, mischt sich da nicht ein) dran. Und wieso geht es innerhalb einer Sekunde an ich "Erneut Verbinden" drücke? Da wartet nix, es wird nix ausgeführt ohne manuelle Aktion. Und von PC geht es immer ohne manuelle Hilfe immer. Es liegt an einer Konfig oder am OpenPLI selber, denn die intern Platte von Receiver 1 sieht man auch nicht. Es wird nichts gemountet, das ist mein Ergebnis. Wieso k.a. die Hardware hat sich nur durch neue Receiver geändert und OpenPli 7 statt 4.

USB1 + USB2 heißen die Platten, alles korrekt.

Eine aktuelle Log-Datei hänge ich hier später gegen 22.30 Uhr an.

mfg

Edited by Kredar, 2 April 2020 - 16:25.

[anudanan]

Sind das die selben Receiver wie damals mit openpli 4.0?
Es kann z.b. am Netzwerktreiber im Openpli 7.2 liegen, das ist ja ein neueres Linux als bei 4.0

Edited by anudanan, 2 April 2020 - 16:27.

[Kredar]

Nein sind neue GigaBlue Quad 4k das ganze Mal zwei. Baugleiche. Die alten wurden mir zu langsam (waren zwei ET9000).

Kann nur froh sein dass das ganze Problem nur nach einem Neustart passiert, sonst hätte ich echt Stress mit der Familie...

mfg

Edited by Kredar, 2 April 2020 - 16:27.

[anudanan]

Das klingt dann wirklich nach einem Netzwerktreiber Thema, wo der Netzwerk Link vermutlich länger dauert als üblicherweise.

Edited by anudanan, 2 April 2020 - 16:30.

[Kredar]

Irgendwas muss da sein, an der Hardware liegt es nicht die ist schnell und gut genug denke ich kann.

Wenn es da Treiberprobleme gehen würde, dann ein zeitliches. Den wie gesagt nachdem "Erneut Verbinden" ist alles okay auch nach Standby ist alles komplett da. Nur beim ersten Start geht es leider nicht.

mfg

Edited by Kredar, 2 April 2020 - 16:33.