[P3f]

@Claus

Korrekt eine Installationsroutine haben wir noch nicht bei der WeTek. Waren in der letzten Zeit wegen der MLd5 zeitlich geopfert worden.

Pit

[skraw]

Das duerfte wohl bedeuten dass ich im Moment nichts wirklich ausprobieren kann. Denn ohne Basis-Installation laesst sich wohl nichts nachinstallieren und ohne Ausgabe-plugin kann ich auch onscreen nichts machen. Gebt mir Bescheid wenns weiter geht.

[MegaX]

Die MLD hat ja nicht nur die Wetek Play sondern auch noch andere Platformen die du testen darfst

[skraw]

Ich schaetze es gibt genuegend PC und RPI Leute. Ich will den PC ja grade loswerden, denn es gibt keine PCI DVB Karten mehr dafuer, ich konnte schon beim letzten Karten-Exitus erst nach Wochen wieder eine beschaffen. Das Ding fass ich nur noch zum entgueltigen Ausschalten an.
Das ist ja grad das Schoene am Wetek. Wenn das Ding hin ist kauft man einfach die naechste Schachtel, vglweise billig und alles drin was man braucht.

[clausmuus]

Hi skraw,

auch ohne Installation kannst Du das meiste auf der WeTek testen. Einziger Haken ist, das Du das Teil nicht ausschalten darfst, oder von vorne anfangen musst, es sei denn Du fertigst zuvor ein Backup Deiner Konfig (z.B. über das Webif) an und spielst das nach dem nächsten Booten wieder ein.
Aber unabhängig davon, sollten sich alle Pakete installieren lassen, die in die Ramdisk passen und da passt ne Menge rein. Dein Installationsproblem sollten wir also ruhig jetzt schon auf den Grund gehen. Es spricht auch nichts grundsätzliches dagegen die Installationsfunktion recht bald nach zu rüsten. Das war in dem Ganzen Version 5 Trubel nur unter gegangen, da die WeTek noch nicht all zu hoch oben auf der Prioritäten Liste steht und stand.
Ausgaben die beim Installieren kommen, stehen nicht vollstendig in den Logs. Es wäre also gut, wenn Du die kopieren und hier im Forum posten würdest.

Claus

[skraw]

Das ist leichter gesagt als getan, denn die Ausgaben passen von der Breite her bei weitem nicht in das Log Fenster...

Mal sehen, das hier ist ein  Versuch "tools" zu installieren, also was ziemlich unverfaengliches, eigentlich:

Code: [Select]

Install tools
Reading package lists...
Building dependency tree...
You might want to run 'apt-get -f install' to correct these:
The following packages have unmet dependencies:
libgdk-pixbuf2.0-0 : Depends: libjasper1 (>= 1.900.1-~1) but it is not going to be installed
Depends: libtiff5 (>= 4.0.3-~1) but it is not going to be installed
Depends: libjbig0 (>= 2.1-~1) but it is not going to be installed
tools : Depends: libpci3 (>= 3.2.1-~1) but it is not going to be installed
vdr-plugin-softhddevice : Depends: libvdpau-sunxi but it is not installable
E: Unmet dependencies. Try 'apt-get -f install' with no packages (or specify a solution).


[clausmuus]

Hi,

wie Du gesehen hast, sind doch die gesammten Logs zu sehen, man muss nur ein wenig scrollen

OK, zurück zu Deinem Problem: Das Paket vdr-plugin-softhddevice ist nicht für die WeTek geeignet, auch wenn es angeboten wird. Da ist noch ein wenig Feintuning unsererseits nötig. Dieses Paket hat nun jedenfalls Abhängigkeiten, die nicht aufgelöst werden können, was vermutlich die beschriebenen Probleme auslöst. Entferne mal das Paket oder boote neu und installiere das nicht.

Claus

[skraw]

Entfernen geht mit aehnlichen Fehlermeldungen nicht wie das Installieren neuer Pakete. Da ist wohl ein ganz neuer Download faellig.

PS: Das softhdhdevice ist uebrigens nicht mein Fehler. Wenn man beim Wetek Download auf die Customize Version klickt erscheint in der bereits vorgefertigten Auswahl das softhddevice bereits selektiert...

PPS: Oder merkt der sich meine fruehere Auswahl irgendwo? Scheint wohl so ...

[mafe68]

Mache mal bevor du dir eine neue Zusammenstellung machst "Auswahl aufheben"

[MegaX]

PPS: Oder merkt der sich meine fruehere Auswahl irgendwo? Scheint wohl so ...

Jepp...wird sich gemerkt, damit du auch nachvollziehen kannst was du in deinem letzten Image an Paketen drinnen hattest.

[skraw]

Ach ja, das Original-Problem dass der vdradmin mit Fehlermeldung nicht aufgeht ist uebrigens genau gleich in meiner neuen Installation mit dummydevice. Daran hat sich nichts geaendert:

Konnte Verbindung zu MLD:6419 nicht aufbauen: IO::Socket::INET: connect: Connection refused

Bitte überprüfen Sie, dass VDR läuft und dass seine svdrphosts.conf richtig konfiguriert ist.

[clausmuus]

Ja, derzeit wird die Auswahl bei individuellen Images noch für alle Plattformen gemeinsam gespeichert. Das muss ich noch trennen.

Hast Du das vdradmin Problem auch auf anderer Hardware (RPI oder BPI), wenn Du da den gleichen Image Type installierst?

Claus

[P3f]

Hallo skraw,

so ich habe nun mal tiefer gesucht und dabei auch eine Installation auf einem BPI (wegen der arm-Umgebung) mit VDRAdmin-AM zu verifizieren. Also auf dem BPI funktioniert die Installation und auch der VDRAdmin-AM, das nur nebenbei.

Dann habe ich das WeTek-Image noch einmal komplett neu auf die SD-KArte gebannt und gestartet. Nachdem ich dann den VDR und auch VDRAdmin-AM nach installiert hatte, konnte ich auch deine Fehlermeldung nachstellen. Wenn man nun auf der Konsole den VDR noch einmal neu startet, dann bekommt man auch den VDRAdmin-AM ganz normal im Webif zur Anzeige.

Auf der Konsole muß es dann so aussehen:(Dann sieht man das der VDR und VDRADmin-AM gestartet und aktiv sind).

Code: [Select]

MLD> ps | grep vdr
22085 root     18900 S    vdradmind
22162 root      4236 S    {runvdr} /bin/sh /usr/bin/runvdr
22229 root     53600 S    /usr/bin/vdr -s /etc/vdr/shutdown.d/rc.action -r /etc/vdr/recording.d/rc.action -w 60 -g /tmp -u root --vfat
22253 root      4108 S    grep vdr 

Das ganze Problem ist aber tiefer, da wir die Installationsroutine noch nicht für die WeTek implementiert haben wird ein Teil halt falsch in den Speicher geschrieben und kann nicht beim ersten Mal korrekt gestartet werden. Das ganze ist also mehr als unsauber.

Wir werden uns nun erstmal darum kümmern, das die Installationssicherheit gegeben ist und die Dateiablage sauber funktioniert. Dann werden auch die Setuproutinen wieder sauber funktionieren.

Aber danke für die Hinweise, dadurch haben wir die Lücke gefunden.

Gruß,

Pit

[skraw]

Das komische an der Sache ist ja, dass alle Prozesse scheinbar laufen (auch vdr und das runvdr Script), der vdradmin-am usw. Alles ist scheinbar da. Aber ich vermute dass die Software mit irgendwas an der "Installation" so ungluecklich ist dass sie sich im Startup halb aufhaengt. Nur dann waere denkbar dass der vdr-Port schon gar nicht aufgeht. Wuerde der Code erst danach "haengen" saehe man im vdradmin-Fenster einfach die Maus auf Busy-Status weil kein vdr am geoeffneten Port antwortet.