Posts by stschulze

    zu 1 und 2: ...braucht es nicht

    zu 4 wenn es ein power-Problem gegeben hat, soll die Kiste aus bleiben, weil Du ja nicht wissen kannst, was das Power-Problem ausgelöst hast. Möglicherweise schickst Du die Kiste sonst ins Nirvana .....

    zu 3: iSetupCfg ist ein Tool, welches aus dem Betriebssystem heraus NVRAM-Variablen ändern kann, d.h. Bios-Zugriff. Der Zugriff funktioniert nur mit Passwort .... siehe Intel-Doku:

    Hi und Danke für euren Einsatz !

    Ich bin gerade dabei den von Intel retournierten NUC mit der 3.5.12 (nativ-mcli) in Betrieb zu nehmen:
    1 Wenn ich in softhddrm.conf -C HDMI-A-1 belasse habe ich nur Ton = kein Bild. Mit -C DP-1 funkt es.

    2 Bitte die /opt/vdr/plugins/menuorg.xlm aktualisieren. Meine ist im Anhang.

    3 Das Zeitupdate ist in rc.local auskommentiert (war in 3.5.10 glaub ich nicht so) ? #ntpdate -q ntp.ubuntu.com

    zu 2: warum sollten wir die Menuorganisation anpassen ?


    zu 3: das Zeitupdate läuft über einen Service ...gehe mal der SMB auf das System und schaue in den Ordner "Systemanalyse". Dort findest Du eine html-Datei, welche das Bootverhalten Deines NUC darstellt. Die Zeitsyncronisation übernimmt der "systemd-timesyncd.service "

    Erschwerend komm hinzu das offenbar immer noch "Sandmännchen" Suchtimer aktiv sind die ich längst im epgsearch gelöscht hatte. Hab mit schon nen Wolf gesucht und finde ums verrecken nicht wo der sich immer wieder die Timer herzaubert?!? Der böse Sandmann sorgt immer wieder mal dafür das mir die Pladde vollläuft :evil::/ Das hat aber wharscheinlich nix mit VNSI selbst zu tun..

    schau mal in /usr/share/vdr/plugins/vnsiserver


    dort werden die von den VNSI-Clients erzeugten timer abgelegt und später in die timerliste bzw. epgsearch übernommen .... ich hatte das mal ...mit einem kodi/vnsi-client einen suchtimer erzeugt, welcher trotz gelehrtem epgsearch immer wieder als timer aufgetaucht ist .......


    evtl. auch alle client ansehen, ob die in den suchtimern oder timern noch etwas drinstehen haben


    funktioniert nach einem route66 bei mir problemlos ....

    zu 2) wozu brauchst Du TB?

    zu 3) stimmt, geht aber auch so

    zu 4) wir hatten in der Vergangenheit mit der Option CEC erhebliche Probleme bzgl. Remote

    zu 5 u 7) braucht es nicht

    zu 6) so weiß der NUC im Problemfall, dass er HDMI 1 nehmen soll

    zu 8 u 9) das ist BIOS default ....ich würde es so auch lassen....

    zu 9) wie das jeder wünscht ....

    Ich versuche jetzt so nach und nach die Logo Dateien auf den Aufnahmen extrahieren zu lassen. Bei den öffentlichen funktioniert das ganz gut. Bei den HD+ Kanälen bekomme ich regelmäßig die Meldung, dass kein Logo gefunden wurde….

    naja eine möglichkeit gibt es noch, die halte ich aber eher für suboptimal ....


    das remoteosd-plugin liest die aus dem svdrpservice-plugin aus ..... in der conf zum plugin steht IP:Port. die IP ist allerdings nicht die IP des lokalen vdr, sondern der kopfstation ....


    ich finde es besser man kann den port in der setup.conf setzen ....schick ist es natürlich in de plugin-einstellungen änderungen machen zu können.


    übrigends .... ich bin sehr angetan von dem markad .... danke für deine tolle arbeit, pflege und weiterentwicklung.

    ich bin gerade dabei hier alles richtig einzustellen ....... gehe ich recht in der Annahme, dass das markad-plugin per svdrp mit dem vdr kommuniziert .... in htop sehe ich, dass der pluginaufruf den svdrpport 6419 verwendet. wie kann ich das ändern ...ich verwende einen anderen Port. möglichweise wäre es hilfreich den svdrpport in den plugin-einstellungen ändern zu können.

    hi,


    leider sind die markad-ergebnisse bei mir nicht irklich gut ....v3.01 letzter Stand.


    Könnte mir bitte jemand einen aktuellen Satz Senderlogos für mein markad zukommen lassen?


    Wie bekomme ich das hin, dass die bei den aufnahmen extrahierten senderlogos in einem verzeichnis gesammelt werden?


    hg

    stephan