Posts by vdrjoe

    Hallo,
    ich versuche die Radiotext information auf einem headless-vdr-server per SVDRPsend abzufragen.
    Die ausgabe von


    bzw.

    Code
    1. xyz@server:~$ vdr -V
    2. vdr (2.2.0/2.2.0) - The Video Disk Recorder
    3. vdrmanager (0.13) - VDR-Manager plugin
    4. radio (1.0.0) - Radio Background-Image/RDS-Text
    5. vnsiserver (1.3.1) - VDR-Network-Streaming-Interface (VNSI) Server
    6. streamdev-server (0.6.1-git) - VDR Streaming Server
    7. live (0.3.0) - Live Interactive VDR Environment
    8. vompserver (0.4.1) - Vompserver plugin by Chris Tallon


    scheint schon einmal auf ein funktionierendes Radio-Plugin hinzuweisen.


    Allerdings erhalte ich mit

    Code
    1. xyz@server:~$ svdrpsend RTINFO
    2. 220 server SVDRP VideoDiskRecorder 2.2.0; Tue Nov 10 21:15:58 2015; UTF-8
    3. 500 Command unrecognized: "RTINFO"
    4. 221 server closing connection


    keine Info bzw. das vorher angebotene Svdrp-Command scheint unbekannt.


    In der setup.conf habe ich (bei gestoppten VDR) bereits die zeile

    Code
    1. radio.Activate = 1


    ergänzt und den VDR neu gestartet.
    Einen Radiokanal stelle ich z.B. über VLC und den streamdev-server ein (von Windows aus, der Ton läuft dann auch dort).
    Ich hatte nun gehofft, die RDS-Infos z.B. per svdrp-comands am Server zur weiteren Verwendung abgreifen zu können.


    Funktioniert das Radio-Plugin nur mit einem realen OSD? (wäre ja fast naheliegend)


    Gruß
    vdrjoe

    zur Info, falls es jemanden mit ähnlichen Probs gibt:


    Der Fehler beim automatischen Compilieren des r8168-Moduls per dkms konnte ich durch Einsatz von fnu's DKMS-Paket aus :
    https://launchpad.net/~fnu/+archive/ubuntu/main-fnu/+packages?field.name_filter=r8168&field.status_filter=published&field.series_filter=a
    beseitigen. Ob die Kiste auch ohne diesen Treiber ginge, (ev. sogar besser?,) werde ich bei Gelegenheit testen.


    Danke
    Joerg

    Tja, mein Urlaub geht zu Ende,
    das muss ich vertagen.


    Danke für die Hilfestellungen.


    Edit:
    Zum Thema r8168:
    die Probleme sind ja nicht (nur) rein Netzwerktechnischer Art, denn das Live-TV-schauen von ARD-HD geht in dieser Konstellation ja (möglicherweise mit "Micro-Rucklern)".
    Das Abspeieln von HD-Inhalten von der HDD ist ja das direkte Problem, wobei SD dann noch funktioniert.
    Eventuell ein Problem mit Interrupt-sharing?

    Fühle mich wie in Punxsutawney.
    nachdem bei obigem apt-get remove auch das linux-image-extra-3.13.0-49-generic entfernt wurde funktioniert eine USB-Tastur nicht => kein Login möglich.
    Hatte aber zum Glück auf dem Boden noch ne PS/2, konnte damit das fehlende -extra- installieren, nun geht eine manuelle Auswahl im grub-Boot-Menue mit der USB-Tastatur wieder
    Allerdings ignoriert grub meine Einträge in /etc/default/grub :rolleyes:
    habe update-grub natürlich ausgeführt.


    Stehe also in etwa da, wo ich vorgestern schon 'mal war- bin allerdings geringfügig schlauer.
    und habe immer noch eine riesige Liste an Kerneln zur Auswahl beim booten.
    reboote ich die Kiste aus der Ferne, dann startet der falsche Kernel.


    Edit:
    Konsekutives entfernen der unerwünschten Kernel hat zunächst dann doch dazu geführt, dass der 3.13.0-49 kernel der "neueste" im System ist, welcher dann auch automatisch von grub geladen wird.


    Allerdings fürchte ich, ein irgendwann aus anderen Gründen durchzuführendes "apt-get update" mit nachfolgendem "apt-upgrade" wird mir wieder 'nen neuen Kernel bringen.
    Danke und Gruß
    Jörg

    Konnte dem dann doch nicht wiederstehen, habe also das oben genannte Komanndo abgesetzt:
    Mit dem erwarteten/befürchteten Ergebis:
    tatsächliche wurde der 3.13.0-53-Kernel entfernt, aber gleichzeitig der 3.13.0-57 installiert. Nach einem reboot ist grub dann in den -57-Kernel durchgestartet.


    Mit den alten Folgen: Live HD-TV geht, HD-Aufnahmen sind unabspielbar, ganz alte SD-Aufnahmen funktionieren.


    Aber es gab einen Hinweis:
    Mein Board benötigt den r8168 Netzwerk-Treiber, welcher bei mir per dkms baut (warum, weiß ich nicht mehr)
    Dieser build ist schief gegangen:


    Meine Vermutung: dieser Fehler trat irgendwann nach 3.13.0-49 erstmals auf.


    Es gibt nun verschiedene Möglichkeiten der Abhilfe:

    • in grub den default-Kernel auf den funktionerenden Kernel stellen, aber kommt ein neuer Kernel dazu, was macht grub dann, wird der Index automatisch hochgezählt?
    • den Fehler beim Treiber-bauen per dkms beseitigen
    • ev. ist mittlerweile in passender Treiber im Kernel dabei?, wie dann umstellen?


    Welcher Weg ist dauerhaft zielführend und möglichst einfach zu lösen?

    Habe ein Backup eingespielt, aber eventuell hätte dieser Hinweis:
    http://askubuntu.com/a/553299


    auf die Funktionalität des "linux-image-extra-x.x.z-j" - Pakets auch weitergeholfen:


    Dort steht zu lesen:

    Quote

    In Ubuntu Trusty 14.04, it appears the USB-HID (keyboard) support is included only in -extras...


    Das entspräche ja genau meinem hier geschildertem Problem.
    Die Installation des entspredchenden -extra-Pakets hätte mir möglicherweise den Zugriff aufs System zurückgegeben.
    Nur zur Info, falls jemand in ähnliche (selbst gestellte) Fallen läuft.

    http://askubuntu.com/questions…kage-for-and-do-i-need-it


    hat es mir erklärt!
    Danke gda!
    Dort (askubuntu) habe ich vermutlich auch die Antwort, warum bei meinem Rettungsversuch (Ubuntu 14.04.2-LTS: Nach OP am offenen Kernel-Herzen kein Login mehr, was tun?) kein Login möglich war:
    http://askubuntu.com/a/553299

    Quote

    n Ubuntu Trusty 14.04, it appears the USB-HID (keyboard) support is included only in -extras...


    Result: stuck keyboard / non-functioning TTY on bootup without this package!


    Wieder 'was gelernt.
    Mal sehen, ob ich noch ' ne PS/2 Tastatur habe!
    cu Jörg

    Hier: ab Zeile 12 aus meinem Anfangspost

    "


    Aber stimmt, wo ich es jetzt nocheinmal lese ist hier von "linux-image-extra-3.13.0-49-generic" die Rede,


    Da muss ich doch mal g**gle fragen, ob das -extra- etwas übelflüssiges ist.


    Jörg

    Mal sehen, wann ich den Mut aufbringe Dir zu folgen, gda.


    Bin erstmal froh, dass die Kiste wieder läuft.


    apt-get sagt aber doch recht deutlich (in GROSSSCHRIFT), dass es diese Kernel gern alle entfernen will ??


    Und warum es den neueren Kernel installieren will?


    So blöd kommt mir mein Ansinnen, die alten Kernel einfach per "rm" aus dem System zu entfernen nun doch nicht mehr vor.


    ich werde das ertmals weiter beobachten (speziell, ao das seltsame Ruckeln/ Abbrechen bei Wiedergabe einer Aufnahme nun tatsächlich weg ist.
    Gruß
    Jörg

    Hallo,
    ich hole mit der Vorgeschichte zunächst etwas aus:


    Zum VDR siehe meine Sig.


    Ich hatte vor einiger Zeit unattended upgrades auf meinem (VDR-) Server (Ubuntu 14.04.1 LTS) nachträglich aktiviert.


    Wir hatten in letzter Zeit einige Stromausfälle in der Gegend, der Server startete demzufolge neu, und verwendete dann den neuesten per unattended updates installierten Kernel.
    So weit so gut.


    Das Problem:
    Letzte Woche war es dann soweit, die Wiedergabe von Aufnahmen stoppte nach einiger Zeit, Ruckler waren an der Tagesordnung. Die zunächst vermuteten Probleme mit der Netzwerkverkabelung und Versuche den möglichen Ort einer schlechten Verbindung durch Umstecken der Netzwerkleitungen zu lokalisieren brachten nur kurze Zeit Linderung.
    Live TV schauen (über Vomp) gingen dabei allerdings völlig ohne Probleme, was ja auch gegen Netzwerk-Probleme spricht.


    Der Hinweis:
    Speicherplatzprobleme auf meiner kleinen SSD führten dann zu einem nicht vollständig durchgeführten unattended update.
    Der Rechner startet nicht, sondern lief in eine Kernel Panic.
    Voller Erstaunen fand ich etwa 20 verschiedene kernel im /boot Verzeichnis.
    Okay, das kommt davon, wenn man der kiste freien Lauf lässt.


    Die Lösung?
    Versuche zeigten, dass bei verwendung des Kernels 3.13.0-49-generic die Problme verschwunden waren, auch zuvor scheinbar nicht abspielbare/"defekte" Aufnahmen können damit problemlos angesehen werden.
    Warum das so ist, wird dann ein anderes Thema.


    Beim manuellen Versuch per mc alle unnötigen Kernel von der Platte zu entfernen, hatte ich mir das System zerschossen (anderer Thread).
    Ein 2 Wochen altes Backup hat den alten Zustand (mit aktivierten unattended upadates) wiederhergestellt


    Die unerwünschten updates habe ich abgestellt:

    Code
    1. root@server:/home/rei# dpkg-reconfigure -plow unattended-upgrades
    2. Replacing config file /etc/apt/apt.conf.d/20auto-upgrades with new version


    Meine Versuche, die unerwünschen Kernel sauber über die Paketverwaltung zu entfernen zeigen allerdings ein unerwartetes Verhalten:
    Ich würde gern den Kernel 3.13.0-49 behalten und zumindest die Neueren entfernen.



    Ich will weder einen neueren Kernel installieren, noch andere als den angegebenen entfernen.
    Was läuft falsch, oder wie kann ich explizit NUR den in derBefehlszeile angegebenen Kernel löschen?


    Danke und Gruß
    Jörg

    Hallo zusammen,
    wer einfach Kernel und zugehörige initramdisks aus dem /boot Verzeichnis löscht ist selbst schuld, ich weiß! (Asche auf mein Haupt!)


    Mein System war Ubuntu- 14.04.1-LTS-Server amd64. mit (zuletzt lauffähig) Kernel 3.13.0-49-generic


    Infolge der von mir blöderweise aktivierten automatischen Sicherheitsupdates sammelten sich im Laufe der Zeit einige Kernel im /boot -Verzeichnis.
    Nicht alle spielten problemlos mit meinem VDR zusammen (anderes Thema).


    Statt diese nun sauber über

    Code
    1. apt-get remove --purge ...


    zu entfernen habe ich diese händisch gelöscht und dabei versehentlich das System zuerschossen (habe das natürlich erst beim nächsten reboot bemerkt ). Ober blöd eben!


    Trotzdem möchte ich retten, was zu retten ist (und dabei verschämt lernen).


    Per Jessie-install mit der rescue/enable=true Kommandzeilen-Option bin ich ins (Jessie)Rescue-System gelangt und konnte nach chroot ins vergurkte /
    mit vielen Mühen einen neuen Kernel installieren (nun 3.16.0-4-generic) , Grub spielt soweit auch wieder, ich kann im Menue navigieren.
    Das lief nur mit einigem Gewürge und der Hilfe von aptitude an der Rettungskonsole. (Ein Problem waren unaufgelöste Abhängigkeiten zwischen dem isc-dhcp-server und irgentetwas mit systemd und pam)
    Es gibt eine Fehlermeldung [fail] beim Systemstart, die rauscht allerdings vorbei.
    Leider hängt das System bereits bei der Initialisierung des Netzwerks.
    Es folgt dann der Login-Prompt, aber spätestens jetz ist die Tastatur tot. Ein Login also nicht möglich; eine dazugesteckte USB-Tastatur wird ebenfalls nicht mehr erkannt.


    Zugriff übers Netz klappt wegen fehlender Netzwerkfunktionalität natürlich auch nicht.


    Gehe ich wieder über die Debian-DVD per chroot ins System, habe ich Zugriff auf das Dateisystem, ein Ping ins Internet funktioniert, per ssh oder telnet komme ich aber nicht auf den Server.
    Kann also nur an der Rettungskonsole tippen.
    In welcher Richtung kann ich suchen?
    Ein funktionierender Login an der Konsole wäre mein erstes Ziel.


    Danke für die Geduld mit einem Ungeduldigen.
    Jörg


    Tja, 120 GB sind wohl doch etwas wenig. da muss ich mal nachsehen wie ich Platz schaffen kann.

    Hallo zusammen,
    meine lange Jahre erprobte vomp-server-client-Insatllation "spinnt" neuerdings etwas.
    Konkret lassen sich die Client-Einstellungen (z.B. OSD-Sprache, Seitenverhältnis etc.) nicht mehr auf dem Server abspeichern.
    Wähle ich z.B. Deutsch als Sprache aus bleibt es bei einem OSD auf englisch.
    Die wichtigen restlichen Funktionen wie z.B. EPG, Timer setzen, Live-TV und Aufnahmen gucken funktionieren immer noch tadellos.
    Lösche ich die client-mac.conf Dateien auf dem Server wird nach/ bei dem nächsten Verbindungsaufbau des vomp-clienten zum Vompserver-Plugin zwar eine entsprechende Datei angelegt, allerdings bleibt diese leer (0 Byte Länge).


    Was geht da schief?
    plötzliche Rechte-Probleme?
    Wieso solle ein Prozess aber eine Datei anlegen können, dann aber nicht hineinschreiben dürfen?
    ich bin etwas ratlos.


    Kann es etwas mit DHCP zu tun haben?
    Früher lief der DHCPD auf dem (VDR-)Server, seit einiger Zeit macht das die Fritzbox.


    Bin für jeden Hinweis dankbar.
    cu Jörg

    dpkg --purge vdr geht auch nicht (ich vermute apt-get remove ruft letztlich dpkg -remove auf)

    Code
    1. dpkg --purge vdr
    2. (Lese Datenbank ... 245648 Dateien und Verzeichnisse sind derzeit installiert.)
    3. Entfernen von vdr (2.1.6-6yavdr2~trusty) ...
    4. postrm called with unknown argument `remove'
    5. dpkg: Fehler beim Bearbeiten des Paketes vdr (--purge):
    6. Unterprozess installiertes post-removal-Skript gab den Fehlerwert 1 zurück
    7. Fehler traten auf beim Bearbeiten von:
    8. vdr


    any hints?