Posts by Razorblade

    Ich brauche für eine Umrüstung einen günstigen SAT>IP Server. Mit 4 Tunern gibt es in der €130 Preisklasse entweder den "Telestar Digibit R1" oder "Megasat SAT zu IP Server 2". Gibt es da Erfahrungswerte, welcher von den beiden mit VDR und satip-plugin besser funktioniert? (Ich weiß, Octopus wäre besser, aber es ist nicht für mich und der Preis ist ein entscheidender Faktor)

    Hehe lustig, ich bin das Projekt auch dieses Jahr erst angegangen, es ist eine GTX960 von EVGA geworden. Da habe ich eine klare Ansage gefunden, dass unter 65°C der Lüsfter komplett aus ist, was bei VDR-Betrieb vollkommen ausreicht. Ich habe allerdings daraus eine Dual-Boot System mit Windows gemacht, da die Steam-Auswahl dann doch etwas größer ist. Das letzte Teil (Attric USB) ist gestern erst eingetroffen, am Wochenende werde ich den vdr dann wohl "produktiv" nehmen.

    Ich würde gern die remote.conf neu anlernen, allerdings kommt auch nach Löschen von /etc/vdr/remote.conf und /var/lib/vdr/remote.conf (ja natürlich, bei abgeschaltetem vdr) keine Aufforderung dazu. Hat sich da bei vdr 2.2.0 oder yavdr 0.6.0 irgendwas geändert?

    Da verkennst Du leider einige Abhängigkeiten. Zwar "können" aktuelle BIOSe auch noch (sogenannter CSM Modus) normal booten, aber das ist (im Vergleich zu nativ UEFI/Fast-Boot) nicht nur langsam sondern ggf. inkompatibel mit parallel installierten Systemen und/oder GPT. Für UEFI Boot muss, je nach Datenträgertyp, eine Voraussetzung erfüllt werden, das hat nicht mit einem "Buggy BIOS" zu tun. Für CD-Boot (und das betrifft imho auch per dd o.ä. auf USB-Sticks geschriebene ISOs) muss ein entsprechender Eintrag im ISO-Header sein. Der ist beim yavdr 0.6.0 nicht vorhanden, deswegen die Vorbehandlung mit mkisofs.
    Für den Boot als Datenträger muss es ein entsprechendes Verzeichnis mit einem Bootloader geben, bin mir nicht sicher ob das beim "Original" yavdr ISO dabei ist, aber anscheinend funktionieren dann einige Zuordnungen nicht.


    An den Moderator: Macht es evtl Sinn die UEFI Diskussion in einen neuen Thread zu verschieben? Das ursprünglich Problem ist ja gelöst...

    Ok, habe mich mal durch den cdrtools-Wust gequält:
    Das eigentlich mkisofs (aus den cdrtools) kennt die Optione "-e" nicht. Debian hat cdrtools irgendwann geforked und mkisofs in genisoimage umbenannt, danach sind auch neue Optionen u.a. das "-e" hinzugekommen.
    Beim "Original" mkisofs geht es mit "-eltorito-platform efi -b boot/grub/efi.img" anstatt "-e boot/grub/efi.img".


    Habe das iso auch mit dem usb-creator auf den Stick gebracht, /cdrom musste ich per "mount -o bind /media /cdrom" einbinden, sonst ging es nicht weiter.
    Jetzt scheitere ich aber an zwei Problemen:


    - Grub installiert sich nicht: meckert was von "grub-efi-amd64-signed konnte nicht nach /target/ installiert werden" (grub-efi-amd64-signed failed to install into /target/)
    - yavdr spuckt beim seed einen Fehler 127, eventuell ein Folgefehler aus der fehlgeschlagenen Grub Installation oder etwas anderes? Gibt es ein Log wo man Details dazu finden könnte? (Mein zweiter Tip wäre das Nichtvorhandensein von /dev/sd<irgendwas>, ich hab nur /dev/nvme0ns1 (NVMe SSD))

    ich nehme alles zurück - auch mit der von mir beschriebenen Methode gibt es Probleme - die Installationsroutine bricht nun bei "Paketmanager konfigurieren" ab.


    Nun habe ich mal das yavdr64-0.6.0-efi.iso mit dem Ubuntu-eigenem 'Startmedienersteller' (aus 15.10) auf den USB-Stick geschrieben, den ich vorher in diesem Tool gelöscht habe.


    Immerhin bin ich nun schon mal problemlos bis zum preseed gekommen - die Installation läuft noch...


    Muss dann der Stick trotzdem noch vorbereitet werden wenn der Startmedienersteller von Ubuntu genutzt wird oder kann man direkt dass per generierte efi-iso nutzen?


    Habe mir gerade mal HW für einen neuen VDR bestellt, mit einer einer NVMe m.2 SSD. Mit komplett abgeschaltetem CSM sind da wahnsinnige Boot-Geschwindigkeiten drin.

    Seit einiger Zeit kann man ja nun auch ohne Umwege ("PS3 emulieren") die Hub-basierten Harmony-FB mit einem PC pairen. Hat das schonmal jemand erfolgreich gemacht? Funktioniert das mit VDR, gibt es evtl. sogar ein fertiges Keymapping? Funktioniert ein Power-on aus S5?


    Ich habe in der Vergangenheit Atric benutzt, bin aber nicht zufrieden, beide haben nach kurzer Zeit den Geist aufgegeben, funktionieren nur noch bei angeschalteten System, nicht für Power-On (5V USB SS liegt an, Lüfter zuckt nur kurz, schaltet das System aber nicht komplett ein). Ausserdem haben die wenigsten neuen Boards noch einen seriellen Port. yausbir scheint ja auch nicht mehr beziehbar zu sein, und irgendwie brauche ich ja dank der Harmony gar kein IR mehr. BT funktioniert bei mir recht zuverlässig (PS3, Wii U), also würde ich es gern mal mit nativer Harmony-Anbindung probieren...


    Wenn das nicht klappt würde ich mir mal den "Atric IR-WakeupUSB eco" anschauen, aber bei dem schlechten Support in der Vergangenheit widerstrebt mir das eigentlich.

    Habe ich schon gemacht, das Ergebnis ist gleich mit meiner alten Config (von meinem eigenen VDR bzw Channelpedia). Wegen NIT scan etc bekomme ich dabei aber auch Transponder und Kanäle, die ich dann später nicht tunen kann.


    szap macht ja auch nichts "magisches" mit der SLOF, wenn es ein spezieller LNB wäre, würde szap auch nicht tunen.


    Habe das ganze jetzt mal weiter eingegrenzt mit szap habe ich hauptsächlich im vertikalen Bereich Probleme (High und Low), aber nicht grundsätzlich:


    Gleicher Transponder, unterschiedliche Ergebnisse.


    Beim VDR hingegen komme ich nichtmal an die Kanäle, die mit szap funktionieren.

    Code
    1. root@vdr-fra:~# szap -c /etc/vdr/channels.conf -x -n 5
    2. reading channels from file '/etc/vdr/channels.conf'
    3. zapping to 5 'SAT.1;ProSiebenSat.1':
    4. sat 0, frequency = 12544 MHz V, symbolrate 22000000, vpid = 0x00ff, apid = 0x0100 sid = 0x0020
    5. using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0'
    6. Version: 5.5 status 1f | signal 9088 | snr ccb0 | ber 00000000 | unc 0000000b | FE_HAS_LOCK


    aber:

    Code
    1. Jun 21 21:26:31 vdr-fra vdr: [417] switching to channel 5 (ProSieben)
    2. Jun 21 21:26:41 vdr-fra vdr: [471] frontend 0/0 timed out while tuning to channel 5 (ProSieben), tp 112544


    Habe sowohl mit als auch ohne DiseqC in vdr.conf probiert (laut Anbieter ohne, nur 14/18V und 22kHz).

    Ich habe einen Cuebitruck nebst Tevii S660 bei einem Hostingprovider zu stehen um einem Freund in den USA deutschen Fernsehempfang zu ermöglichen. Leider habe ich (neben Probleme mit dem Treiber an sich, siehe: Probleme mit Firmware auf Ubuntu 15.04 (ARM) ) diverse Tuningprobleme:


    Ich habe mir eine channels.conf auf channelpedia zusammengestellt, nur SD und nur unverschlüsseltes Fernsehen. Aber so richtig klappt es nur mit ausgesuchten Transpondern.


    Fehlerbild VDR:
    - bei fast allen Sendern (außer ZDF und einige Dritte) "timed out while tuning" und kein epg


    Danach mal mit szap probiert (gleiche config wie vdr!):


    1. "Das Erste" FE_LOCK -> tuned
    2. "ZDF" FE_LOCK -> tuned (ging ja schon im vdr)
    3. "RTL-Gruppe" kein Lock (erklärt also warum es im vdr nicht geht)
    4. "Pro7Sat1-Gruppen" FE_LOCK -> tuned


    Ich habe also Sender die ich mit szap tunen kann, aber nicht mit vdr (wie kann ich das debuggen?) und Sendern, die nichtmal mit szap gehen.


    Sehr merkwürdige Geschichte! Bei mir zu Hause klappte es noch alles, es auf den Empfang zu schieben wäre aber auch zu einfach, mind. ARD und Sat1/Pro7 lässt sich ja mit dem Gerät tunen, nur der VDR mag nicht.



    Hat noch jemand Idee für's Troublehsooting?

    Ja das wars, bis auf live hat jetzt alles durchkompiliert und deb's erzeugt.


    Bei live war doch noch die Sache mit der vdr-2.2.0 Kompatibilität, das Probleme dürfte eigentlich nicht an der Architektur liegen?!?

    Update: Wenn ich "override_dh_usrlocal:" (also leer) in die <source>/debian/rules hinzufügen läuft der build durch, das Plugin wird dann aber auch in /usr/local/lib/vdr/ installiert


    Update2: pkgconfig war ein guter Hinweis, mit einem find / -name 'vdr*' habe ich noch ein altes (von einer manuellen vdr installation) pkgconfig gefunden, was anscheinend nach /usr/local zeigte
    Hab das jetzt mal alles abgeräumt und baue von vorn (jetzt wieder unstable-vdr trusty), werde dann berichten!

    Kein Cross-Compiling, läuft alles auf dem System selbst (wenn auch etwas langsam).


    Ich habe das deb-src Repo *heute* eingebunden und anschließend angefangen zuerst vdr zu bauen (ging), vdr und vdr-dev zu installieren (ging), dann vdr-plugin-xyz zu bauen und hier kommen die Probleme.


    EDIT:
    Mit vdr-testing genau das gleiche Problem. usr/local scheint innerhalb des Builds benutzt zu werden, dahin zeigt jedenfalls das "install" aus dem make.


    Hier mal der komplette Build-Log des vdr-plugin-suspendoutput (nach Installation eines soeben heruntergeladen, kompiliertem und installierten vdr-2.2.0):


    pkgconfig sieht sauber aus (kein local):