Posts by joerg74

  • (gelöst) Asrock Q1900M: kein Netzwerk

    Nabend Forum,
    ich habe hier ein (Hardware-) Upgrade durchgeführt und das Mainboard gegen das Asrock Q1900M getauscht - ohne Neuinstallation von yaVDR. Vor dem Tausch hatte ich noch ein dist-upgrade gemacht, so dass yaVDR recht aktuell sein sollte. Ich hatte zwar auch dieses NFS-Kernel Problem, nach ein paar Neustarts usw lief aber alles wieder.
    Komischerweise funktioniert das Netzwerk nicht. Im Bios Setup funktioniert es, ich konnte per Internet das Bios updaten. Nur unter yaVDR zeigt mir ifconfig nur "lo" an.
    Das onboard-LAN wird offensichtlich nicht erkannt.
    dmesg listet einen RTL8168g/8111g bei eth0
    und weiterhin: iPv6:ADDRCONF(NETDEV_UP): eth0: link is not ready

    Was kann ich tun?
    Besten Dank und viele Grüße
    Jörg

  • [0.5] Kein Ton über HDMI, die Xte

    Noch eine Ergänzung: Nach einem dist-upgrade wollte der VDR nicht mehr, so dass ich die 0.5.0a gestern Abend neu installiert habe. Dort wieder das gleiche Problem - und die gleiche Lösung. Diesmal habe ich nur den HDMI-Eingang am Plasma gewechselt und der Ton funktionierte. Danach konnte ich dann auch die passende Auflösung (1280x720@50Hz) im WFE auswählen (das ging vor dem Umstecken nicht), sogar ohne Custom Template.

    Wie immer ein großes Lob an die Entwickler!

    Viele Grüße
    Jörg

  • [0.5] Kein Ton über HDMI, die Xte

    Hallo Murry,
    Danke für deine Hilfe. Ich habe deine Tips befolgt (dist-upgrade und die softhddevice.conf angepasst), allerdings hat das nicht geholfen. Mir kam das alles spanisch vor, ich hatte auch irgendwo hier im Forum gelesen, dass das an einer kaputten edid.bin liegen könnte.
    Deshalb habe ich den VDR mal an den LCD im Schlafzimmer angeschlossen und siehe da, Ton lief!
    Wieder zurück im Wohnzimmer: Ton lief. Verrückt... Im Wohnzimmer hatte ich einen anderen HDMI Eingang benutzt, allerdings glaube ich nicht, dass es daran lag. Nach einem Klick auf Bildschirm suchen im WFE war auch meine alte Modeline wieder da.

    An Alsa lag es also nicht.

    Vielen Dank und Gruss
    Jörg

  • [0.5] Kein Ton über HDMI, die Xte

    Hallo Forum,
    ich bin nun von der 0.4 auf die 0.5 umgestiegen. Die Gyration wird wieder auf Anhieb erkannt, super.
    Der HD-Ready Plasma läuft durch eine passende Modeline im custom template auch mit 1280x720@50Hz.
    Als Frontend benutze ich die Voreinstellung Softhddevice. Erst war das OSD zu groß, aber über

    Code
    vdr-dbus-send /Setup setup.Set string:OSDSkin string:classic


    habe ich dann ein Skin auswählen können, das besser zu meiner Auflösung passt.

    Nur: Den Ton über HDMI bekomme ich nicht hin. Über SPDIF klappt, aber nicht über HDMI. Unter yaVDR 0.4 lief das auf Anhieb.

    Es ist alles mit alsamixer entmuted und auf 100%.
    Im Webfrontend habe ich Ausgabe an allen Geräten aktiviert. HDMI-Passthrough/Stereo bringt keine Ton-Ausgabe am Fernseher.

    In diversen Forumsbeiträgen hier lese ich von Leuten, die device 7 einstellen und dann gehts. Nur habe ich kein HDMI auf 7.

    Hier meine aplay -l Ausgabe:


    Stelle ich im WFE HDMI Passthough ein, sieht die /etc/asound.conf so aus:

    Code
    pcm.!default {
        type hw
        card 0
        device 3
}


    Das müsste doch eigentlich passen, oder?

    Hat jemand 'ne Idee?

    Viele Grüße
    Jörg
    Ich weiß nicht, ob es weiter hilft, aber hier noch die Ausgabe von aplay -L

  • yaVDR 0.4: Machnmal kein Ton nach S3

    Hallo Forum,

    yaVDR läuft an sich wirklich super, allerdings ist die Kiste von Zeit zu Zeit stumm (nicht gemuted, sondern die Soundkarte is offensichtlich deaktiviert). Xine läuft hier als Frontend. Ein Umschalten auf XBMC und wieder zurück hilft genauso wenig wie ein VDR-Neustart per OSD oder Webfrontend.
    Starte ich den Rechner jedoch neu, funktioniert es wieder.
    Ich fahre nicht komplett runter, sondern nur in den S3-Modus. Der Plasma hängt am HDMI-Port des Mainboards und ist aus, wenn so etwas passiert (muss aber nichts heißen). Reproduzierbar habe ich das aber noch nicht hinbekommen. Scheint irgendwie mit dem Aufwecken aus S3 zu tun zu haben, dann vergisst er offensichtlich manchmal die Soundkarte zu aktivieren.

    Ich hoffe ich werde jetzt licht gelyncht, weil ich keine Logs habe. Sorry, ist ein bisschen Kristallkugelschauen, aber ich sitze gerade nicht vorm yaVDR-Rechner. Vielleicht könnt ihr mir ein paar Tips geben, wo ich mit der Fehlersuche starten kann.

    Gruß
    Jörg

  • Nur kurz Danke sagen (Tagebuch eines Umstiegs)

    Würde es nicht vielleicht Sinn machen eine Liste der direkt unterstützten Fernbedienungen z.B. unter "Hardwarevoraussetzungen" zu erstellen? Dann holt man sich vor einfach eine Passende...

    Das Widerspricht zwar etwas dem Bastelgedanken, aber wenn die FB direkt funktioniert, kann man sich mit mehr Elan auf die anderen Baustellen stürzen (Vernetzung, iVDR, MTP-Center...)

    Gruß
    Jörg

  • [gelöst] Gyration Fernbedienung: Farbtasten funktionieren nach dem letzten dist-upgrade nicht mehr.

    Noch einmal das Modul entladen und das dkms de- und wieder installiert. Nach einem Reboot, habe ich es noch einmal mit rmmod / modprobe versucht.

    Jetzt funktionieren die Farbtasten.

    Mal schauen, wie es nach einem weiteren Neustart aussieht...
    ...nach einem Reboot funktionieren sie nicht mehr, allerdings hilft rmmod / modprobe, und sie funktionieren wieder.

    "modinfo hid-gyration":

    Code
    filename:       /lib/modules/2.6.38-13-generic/updates/dkms/hid-gyration.ko
license:        GPL
srcversion:     8FEF7F5EC8532DF1FBDC218
alias:          hid:b0003v00000C16p00000008
alias:          hid:b0003v00000C16p00000003
alias:          hid:b0003v00000C16p00000002
depends:        hid
vermagic:       2.6.38-13-generic SMP mod_unload modversions

    "dkms status":

    Code
    hid-gyration, 3101EU, 2.6.32-24-generic, i686: built
hid-gyration, 3101EU, 2.6.38-13-generic, x86_64: installed
nvidia-current, 270.41.06, 2.6.38-12-generic, x86_64: installed
nvidia-current, 270.41.06, 2.6.38-11-generic, x86_64: installed
nvidia-current, 270.41.06, 2.6.38-13-generic, x86_64: installed
ati-remote, 0.0.1, 2.6.38-12-generic, x86_64: installed
ati-remote, 0.0.1, 2.6.38-8-generic, i686: built
ati-remote, 0.0.1, 2.6.38-13-generic, x86_64: installed

    nach dem Reboot (Farbtasten funktionieren nicht)
    "dmesg | grep hid"

    Code
    [    3.902945] usbcore: registered new interface driver usbhid
[    3.902947] usbhid: USB HID core driver
[    3.940347] gyration 0003:0C16:0002.0001: input,hiddev0,hidraw0: USB HID v1.10 Keyboard [Gyration Gyration RF Technology Receiver] on usb-0000:00:02.0-3/input0
[    3.949583] gyration 0003:0C16:0002.0002: input,hiddev0,hidraw1: USB HID v1.20 Mouse [Gyration Gyration RF Technology Receiver] on usb-0000:00:02.0-3/input1
[    4.330233] generic-usb 0003:1241:F767.0003: input,hidraw2: USB HID v1.10 Keyboard [HOLTEK Wireless 2.4GHz Trackball Keyboard] on usb-0000:00:04.0-3/input0
[    4.342573] generic-usb 0003:1241:F767.0004: input,hiddev0,hidraw3: USB HID v1.10 Mouse [HOLTEK Wireless 2.4GHz Trackball Keyboard] on usb-0000:00:04.0-3/input1


    Und nach dem Ent- und Neuladen:

    Code
    [  170.715896] gyration 0003:0C16:0002.0001: input,hiddev0,hidraw0: USB HID v1.10 Keyboard [Gyration Gyration RF Technology Receiver] on usb-0000:00:02.0-3/input0
[  170.716614] gyration 0003:0C16:0002.0002: input,hiddev0,hidraw1: USB HID v1.20 Mouse [Gyration Gyration RF Technology Receiver] on usb-0000:00:02.0-3/input1

    Hilft das?

    Gruß
    Jörg

  • [gelöst] Gyration Fernbedienung: Farbtasten funktionieren nach dem letzten dist-upgrade nicht mehr.

    Beim letzten dist-upgrade hatte ich irgendwas mit "gyration" mitbekommen... Jedenfalls funktionierten die Farbtasten am Anfang und nach diesem Update nicht mehr.

    hid-gyration-dkms hatte ich mit sudo apt-get purge deinstalliert und danach mit sudo apt-get install wieder installiert. Da da keine Fehler auftauchten, gehe ich davon aus, dass das geklappt hat...

    Wenn die Farbtasten mit evtest keine Reaktion zeigen, woran kann das dann liegen?

    Gruß
    Jörg

  • [gelöst] Gyration Fernbedienung: Farbtasten funktionieren nach dem letzten dist-upgrade nicht mehr.

    Hallo Experten,

    nach der Installation von yaVDR 0.4 funktionierte meine Gyration GYR3101EU ootb, inklusive der Farbtasten. Vorgestern (28.11.2011) habe ich dann wieder mal ein dist-upgrade gemacht und nun funktionieren die Farbtasten nicht mehr...
    Alle anderen Tasten funktionieren auf der Fernbedienung.

    sudo evtest /dev/input/event2 -> Alle Tasten (bis auf die Maus) liefern eine Anzeige, keine Reaktion bei den Farbigen Tasten

    sudo ir-keytable -t --device /dev/input/event2 -> Alle Tasten (bis auf die MAus) liefern eine Anzeige, keine Reaktion bei den Farbigen Tasten

    Auch die Deinstallation und erneute Installation von hid-gyration-dkms hat nichts gebracht.

    Wie sieht es denn bei denn anderen Gyration-Benutzern aus, funktionieren die Farbtasten?

    Gruß
    Jörg

  • [gelöst] Recordings vom Server werden nicht automatisch eingebunden

    Hallo,

    wie kann ich denn das Skript /etc/init/mhddfs-vdr.conf manuell starten? Oder wie kann ich mich zu Testzwecken als Benutzer "vdr" anmelden?

    Den Eintrag in der fstab habe ich wieder auskommentiert und nach einem Reboot liefert mir "mount" u.a. folgende Ausgabe:

    Code
    /srv/vdr/video.01;/srv/vdr/video.00 on /srv/share/vdr type fuse.mhddfs (rw,nosuid,nodev,user=vdr)

    Das mit dem Zusammenführen klappt scheinbar doch.
    Mit

    Code
    sudo su -c "ls /srv/share/vdr" vdr

    werden mir auch alle Aufnahmen angezeigt.

    Am WohnzimmerVDR taucht das Verzeichnis aber trotzdem nicht auf.

    Da mir nicht ganz klar war, warum der mhddfs Befehl in dem init-Skript unbedingt als User vdr ausgeführt werden muss, habe ich das mal ohne versucht. Der binmount wird im Skript ja auch ganz "normal" ausgeführt. Dazu wurde in /etc/init/mhddfs-vdr.conf folgende Zeile verändert:

    Code
    su -c "mhddfs ${DIRS%%,} $SHARE" vdr

    wurde ersetzt duch:

    Code
    mhddfs ${DIRS%%,} $SHARE


    mount liefert dann (nach einem Neustart):

    Code
    /srv/vdr/video.01;/srv/vdr/video.00 on /srv/share/vdr type fuse.mhddfs (rw,nosuid,nodev)


    Hat also geklappt. Und das Beste ist, dass die Aufnahmen nun auch auf dem WohnzimmerVDR erscheinen!

    Vielleicht muss das init-Skript grundsätzlich angepasst werden?

    Gruß
    Jörg

  • [gelöst] Recordings vom Server werden nicht automatisch eingebunden

    Steffen: Super, dann müsste es ja alles klappen.

    Keine_Ahnung:

    Quote

    Entscheide dich für video.00, video.01, video.02 ODER mhddfs. Beides zusammen ergibt keinen Sinn

    Das war nicht meine Entscheidunug. Ist doch so voreingestellt:

    • Unter /srv/vdr/ die video.xx Verzeichnisse für den lokalen VDR
    • Unter /srv/share/vdr die per mhddfs zusammengefassten video.xx Verzeichnisse für NFS bzw. den entfernten VDR im Netzwerk.

    Oder hab' ich was falsch verstanden?

    Quote

    Warum fasst du deine Daten HDDs nicht einfach zusammen unt mountest die auf den Server unter "/srv"

    Wie kann ich das bei meiner Konfig machen (s.o.)?

    Gruß
    Jörg

  • [gelöst] Recordings vom Server werden nicht automatisch eingebunden

    Edit:
    Hi Steffen,

    da warst du wohl schneller ;)
    Demnach werden die video.xx-Verzeichnisse in umgekehrter Reihenfolge zusammengefasst (ich bin Skript-technisch nicht so der Held)?

    Gruß
    Jörg

    :Edit Ende

    Ich habe mir die /etc/init/mhddfs-vdr.conf mal angeschaut. Eigentlich müsste das auch bei mir funktionieren, aber vielleicht habe ich auch bei video.01 vergessen die Rechte anzupassen.

    Mal eine grundsätzliche Frage zu dem Skript:

    Der VDR verwaltet ja seine Aufnahmeverzeichnisse in /srv/vdr/ selbstständig und legt entsprechende Symlinks an, wenn die erste Platte voll ist.
    Die Symlinks haben aber Priorität vor den "echten" Dateien, wenn die Aufnahmeverzeichnisse per mhddfs in der Reichenfolge video.00, video.01, video.02,... zusammengefasst werden. Das würde also nicht funktionieren and einem entfernten Rechner nicht. Besser wäre es die Aufnahmeverzeichnisse in umgekehrter Reihenfolge zusammenzufassen, also video.02, video.01,video.00.

    Kann man das mit dem Skript so umsetzen?

    Gruß
    Jörg

  • [gelöst] Recordings vom Server werden nicht automatisch eingebunden

    Quote

    /srv/share/vdr enthält die video.00/01/02 per mhddfs zusammengefasst. Das einhängen des Ordners mittels mhddfs passiert durch /etc/init/mhddfs-vdr.conf


    Danke. Das schau ich mir heute Abend mal an.

    Quote

    Was ich jetzt nicht ausschliessen würde, wäre das mhddfs oder der upstart Job Probleme mit dem Bindmounts hat.


    Auf dem WohnzimmerVDR habe ich ebenfalls einen Bindmount für das video.00 Verzeichnis. Dort hat mhddfs keine Probleme gehabt.

    Quote

    nfs Freigabe des Ordners sollte ohne Probleme funktionieren


    Wenn video.00 fast voll ist, speichert der VDR die Aufnahmen in video.01 und legt in video.00 nur Symlinks an. Wenn ich nun nur video.00 per nfs ins Netzwerk stelle, werden diese Symlinks wohl nicht mehr funktionieren...

    Danke für eure Hilfe
    Jörg

  • [gelöst] Recordings vom Server werden nicht automatisch eingebunden

    Kann ich nachvollziehen, dass das nicht immer nachvollziehbar ist...

    Auf den zusätzlichen Platten habe ich nicht nur Aufzeichnungen in video.00, sondern in weiteren Unterordnern neben video.00 auch Avi-Videos, mp3-Dateien, Downloads und die "Eigenen Dateien" von meiner Frau und mir.
    Wenn ich die Platten so einbinden würde, wie du das vorschlägst, sähe das hinterher so aus:
    /srv/vdr/video.00/video.00
    /srv/vdr/video.00/files
    /srv/vdr/video.00/mp3
    /srv/vdr/video.00/photos
    /srv/vdr/video.00/downloads
    /srv/vdr/video.00/videos

    Letztendlich habe ich doch keinen Nachteil, wenn ich es auf meine "umständliche" Weise mache, oder?

    Gruß
    Jörg

  • [gelöst] Recordings vom Server werden nicht automatisch eingebunden

    Moin Forum,

    Sowohl auf meinem Wohnzimmer-VDR, als auch auf dem Server habe ich nun yaVDR 0.4 installiert. Erst einmal ein großes Lob an die Entwickler - da habt ihr saubere Arbeit geleistet!

    Ich hatte nun etwas Probleme meine zusätzlichen Festplatten ins System einzubinden, zumindest was das automatische Einhängen der Aufnahmen vom Server auf dem WohnzimmerVDR angeht.

    Auf dem Server habe ich folgende Konstellation: yaVDR habe ich auf eine kleine Festplatte installiert (sda), die Mediendaten liegen auf zwei weiteren Platten sdb (1,5TB) und sdc (1TB). Bis jetzt liegen alle Aufnahmen unter sdb1/video.00. Weiterer Platz steht dem VDR unter sdc1/video.01 zu Verfügung.

    Die zusätzlichen Platten habe ich per fstab gemounted und die Verzeichnisse mit bind entsprechend umgebogen. z.B.:

    Code
    #mounten
/dev/sdb1 /mnt/sdb1 xfs defaults 0 2
/dev/sdc1 /mnt/sdc1 xfs defaults 0 2
#Ordner umbiegen
/mnt/sdb1/video.00 /srv/vdr/video.00 none bind 0 0
/mnt/sdc1/video.00 /srv/vdr/video.01 none bind 0 0


    Die Berechtigungen auf den Benutzer vdr gesetzt (vorher war alles root zugeordnet, da vorher easyVDR drauf war):

    Code
    sudo chown -R vdr:vdr /srv/vdr/*


    In einem anderen Beitrag habe ich gelesen, dass in /etc/exports die crossmnt option hinzugefügt werden muss:

    Code
    /srv/share/vdr	*(rw,fsid=4,sync,crossmnt,no_subtree_check,all_squash,anongid=666,anonuid=666)


    (Jaja, wurde von mir auch entsprechend "getemplatet" ;)
    Nun tauchten die Aufzeichnungen aber trotzdem nicht auf dem WohnzimmerVDR auf. Es gab zwar ein Verzeichnis /srv/vdr/video.00/yaVDRserver, das war aber leer.

    Wie ich feststellen musste, war auf dem Server das Verzeichnis /srv/share/vdr nicht in Ordnung. Auf dem WohnzimmerVDR war es auf /srv/vdr/video.00 gemountet (zumindest sagte mir das der Befehl mount). Auf dem Server funktionierte diese Verbindung nicht (im MC rot mit Ausrufezeichen).

    Wieso macht man das überhaupt so? Man könnte doch auch direkt das video.00 Verzeichnis per nfs verteilen.
    Vermutlich würden dann die Links zu einem weiteren Video-Verzeichnis (video.01, video.02 etc) nicht funktionieren?

    An welcher Stelle wird /srv/vdr/video.00 denn auf /srv/share/vdr umgebogen? In der /etc/fstab zumindest nicht...

    Ich habe nun auf dem Server in der /etc/fstab folgenden Eintrag hinzugefügt:

    Code
    /srv/vdr/video.00 /srv/share/vdr none bind 0 0


    Und jetzt funktioniert es erst einmal. Ich befürchte nur, dass das nicht mehr funktionieren wird, wenn auch Aufnahmen in video.01 landen.

    Viele Grüße
    Jörg