Beiträge von core_man_2000

    @utilitiy: verloren ist gar nix, ich habe alle Dateien, die vorher auf 00 oder 01 waren auf das NAS kopiert. Ganz blöd bin ich dann doch nicht. Verifiziert hab ich es mit dem dockstar vdr, danach hab ich srv und die sdb1 Platte plattgemacht.
    Offenbar war der Fehler die Annahme, dass 00 und 01 gleichberechtigt sind.
    nach umbennnen von 01 nach 00 und umgekehrt wird wohl alles wieder funktionern.


    Aber die ganz Aktion habe ich ja auch deshalb gemacht, weil mein Wunschszenario ist (s.o.):


    yavdr nutzt 00 (LOKAL vorhanden),weil es dann im Prinzip unabhöngig ist vom NAS.
    Wenn 00 voll, dann ausweichen auf 01 (in der Hoffnung dass das NAS dann auch da ist)
    Ich will vermeiden, das ich in die Schwierigkeiten kome (wie öfters beschrieben hier), dass vdr nicht mag wenn beim booten das NAS nicht da ist (weil schläft) und daher kein video.00. soweit bin ich aber noch nicht, ist ja noch ganz neu dasNAS ..


    Hab ich ne Chance, das Wunschszenario zu erreichen?

    ...ich meine, dass die menuentries schräg sind, ist ein "Feature" von grub: bei update-grub liest grub die /boot Verzeichnisse der vorhandenen Partitionen und übernimmt sie relativ unkritisch, statt die UUIDs anzupassen. Es funktioniert besser, wenn nur auf einer einzigen Partiiton grub installiert ist, dann schiesst er sich nicht selbst ins Knie, sondern macht bei update-grub das, was man sich in deinem Szenario wünscht.
    Kann ich grad nicht durch einen Verweis belegen, hat sich nur so in meinem Gedächtnis gefunden.

    das alte video.00 ist immer noch da, nur leer. Neue Aufnahmen werden auch auf beiden 01 und 00 angelegt, mit gegenseitiger Verzeigerung.
    Zurückkopieren ist nicht der Sinn der Sache, nämlich die Daten aufs NAS auszulagern, so dass man von überall aus drankommt. die sdb1 Platte ist nämlich jetzt im NAS :)


    Wenn ich dich recht verstehe, brauche ich also video.00 mit den verzeigerten Verzeichnissen.
    video00 ist jetzt halt weg, weil ich der Meinung war, wenn alles auf video.01 ist, muss reichen. tut ja auch mit dem vdr auf der dockstar (die allerdings gar kein video.01 hat)
    Und im Zuge des Umbaus war /srv eh fällig...
    Hm, würde es was helfen, 00 und 01 zu tauschen?
    Oder gibts nen Trick, die Verzeigerung wieder herzustellen?

    Seit einigen Tagen bin ich Besitzer eines Synology NAS.
    dabei habe ich nun folgendes gemacht:
    vorher:
    - yavdr hatte Platte "sdb1" mit einen Riesenberg an Aufnahmen
    - diese waren nach /srv/vdr/video.01 gemountet
    - /srv ist auf einer kleineren Partition "sda7" gemountet
    - alles war "schön" :)


    jetzt:
    - NAS hat shared NFS folder mit den ganzen rüberkopierten Aufnahmen
    - das Verzeichnis ist nach /srv/vdr/video.01 gemountet per NFS
    - /srv wie oben auf die gleiche extra Partition gemountet. Ich habe den Inhalt von /srv/vdr/video.00 gelöscht, weil ich alle Daten auf das NAS kopiert habe


    Was passiert:
    - die Recordings sind prima gemountet und im Filesystem sichtbar, mit mode 777, (aber nicht Benutzer/Gruppe vdr:vdr)
    - yavdr sieht keine Recordings, zumindest ist die Liste leer auch nach aktualisieren
    - Aber er kann wohl was mit dem NAS-Verzeichnis anfangen, denn er schreibt fröhlich den Livebuffer drauf, und Aufnahmen landen auch dort
    - Weiterhin hab ich auf ner dockstar noch einen vdr rennen (wheezy mit vdr installiert "normal" mit apt-get aus den wheezy Paketquellen). Der sieht die Aufnahmen und kann sie prima wiedergeben, und auch auf das Verzeichnis aufnehmen. (Ebenfalls nicht mit vdr:vdr).
    Was geht da schief? Meine Vermutung ist, dass das Problem ist, dass video.00 leer ist und keine links mehr enthält nach video.01


    Was soll passieren:
    - Zunächst soll yavdr natürlich die Aufnahmen "sehen"
    - Ziel für Aufnahmen/Livebuffer ist: yavdr soll die lokale Platte, also Verzeichnis /srv/vdr/video.00 nehmen zum schreiben, erst wenn das voll ist, das NAS


    Hat jemand einen Rat?
    - wie kann ich (falls das nötig ist) die gegenseitige Verzeigerung wieder herstellen?
    - wie kann ich das Wunschszenario herstellen?
    Danke
    (Sorry für das längliche Posting)

    An meiner Dockstar hängt ein Pearl LCD. LCD4linux wird beim booten mitgestartet, so dass CPU etc angezeigt wird.
    Jetzt habe ich festgestellt, dass der LCD4linux-Prozess mindestens 12% CPU verbrät. Wenn ich zB ein File auf die dockstar kopiere, geht der Verbrauch sogar auf 30-40%% hoch (dann bleibt für smbd nur noch der Rest...)


    wenn ich einmal killall lcd4linux sage und es neu starte mit /etc/init.d/lcd4linux start, ist alles wie gewohnt, unter 2 %.
    Ich habe wheezy mit kernel 3.2.0-4 installiert.


    Hat jemand eine Idee, woran das liegen könnte?

    Ich hab bei meiner dockstar auch wheezy installiert, auch mit den "üblichen" Problemen (falsches debootstrap, perl). Das löst man durch simples Löschen oder umbennen im nand.
    Zum Schluss hakts nochmal:
    Was passiert ist bei Jeffs wheezy script, dass es den kernel der Version 3.2.0-4 lädt, aber versucht, das boot image für 3.2.0-3 zu machen.


    Man kann das reparieren durch manuelles Eintippen nach chroot auf den stick von

    Code
    cd /boot
    mkimage -A arm -O linux -T kernel  -C none -a 0x00008000 -e 0x00008000 -n Linux-3.2.0-4 -d vmlinuz-3.2.0-4-kirkwood uImage
    mkimage -A arm -O linux -T ramdisk -C gzip -a 0x00000000 -e 0x00000000 -n initramfs-3.2.0-4-kirkwood -d initrd.img-3.2.0-4-kirkwood uInitrd


    Was beim mir nicht von Erfolg gekrönt war, direkt mittels chroot den 3.3.x kernel zu installieren. danach war die Installation futsch und ich durfte von vorne anfangen. (das "Zwischenspeichern" von funktionierenden Ständen vom Stick auf Platte und zurückladen mittels dd dauert auch ewig, da ich zu geizig für schnelle sticks bin :) )

    Auch im S5?


    Man könnte noch versuchen die USB-Module zu entladen.
    Es gibt auch irgendwie die Möglichkeit den USB-BUS zu resetten, wenn ich mich nicht irre.


    Nun ja, die Box hat halt ein eigenes Netzteil, daher hängt sie natürlich immer am Strom. Blöderweise zeigt linux-media-dkms nicht mehr über die LED was sinnvolles an. lilianin hat noch mit rot/grün irgendeinen status angezeigt. Jetztist sie immer orange...
    Früher wars so, dass die Box rot angezeigt hat, wenn Strom aber keine USB Verbindung, und grün wenn Verbindung.


    ich hab drin, wie im anfangspost erwähnt:

    Code
    ~$ more /etc/yavdr/force-reload-modules.list
    dvb_usb_ttusb2
    dvb_usb_pctv452e
    dvb_usb


    wie könnte das mit dem bus reset gehen?

    Die DVB Box hat (leider) immer Strom. Daran kann es nicht liegen. Ich hab ja auch mal alles, was ich an Modulen gefunden hab, in das starte-neu-beim-aufwachen File eingetragen. Aber Du hast mich noch auf eine Idee gebracht, mein board hat 2 verschiedene sorten von USB anschlüssen: bei manchen funktioniert zB das Aufwecken aus S3 mittels FB, bei anderen nicht. ich probier mal einfach alle USB ports aus, an die ich den Empfänger stecke. Ist halt ein wenig langwieriges trial and error Verfahren.


    und wenn ich mich recht erinnere, waren auch immer die aufnahmen kaputt bzw wenn ich im LB zurückspule, sind die Klötzchen an der gleichen Stelle wiedergekommen.

    Auch bei mir ist tatsächlich das "Wunder" geschehen! ;D
    Neuinstallation von CD, vdr-stable PPA getauscht gegen meins, dist-upgrade sowie linux-media installiert (das kam nicht mit).


    Und Klötzchenfreies schauen nach Aufwachen! Auch mit LB!


    So jetzt heisst es Disziplin waren und nicht mehr dran rumspielen :rolleyes:


    naja, ein paar plugins fehlen schon noch. Aber vorher die Partition sichern.

    So, jetzt habe ich doch ein Problem: wenn ich mittels des webinterfaces irgendein Paket nachinstallieren will, krieg ich folgende Fehlermeldung:


    ich hab jetzt rausgefunden, dass das abi-teil ein dummy-Paket ist, nur was bedeutet das? kann ich das irgendwie reparieren?


    als workaround dachte ich mir:
    wenn ich aus meinen ppa mit das passende deb file lade und mittels dpkg installiere, gibts keinen Fehler, aber das plugin wird wohl auch beim starten des vdr nicht mitgenommen. War ich da jetzt zu naiv? (in dem Fall remoteosd und svdrpservice). Muss ich da was von Hand eintragen irgendwo?

    Also mir sind tomaten, paprikas und ungarn egal und ich will auch nicht wissen, wie das mit yavdr zusammenhängt, aber ganz und gar nicht egal ist mir, dass LB rausfliegt. :§$% :§$% :§$% :§$%
    Somit wird mir das yavdr Teil nämlich wertlos. "People ignore software that ignores people" - damit ich diesen Spruch nicht in die Tat umsetzen muss, probier ich mal die eigenes-ppa-Variante.
    So ein ppa (mein eigenes also) hab ich angelegt. Wat nu?
    Wie krieg ich jetzt die richtigen Versionen der richtigen Dateien da rein? und ausserdem noch die Dateien vom "besten Freund"... 8)


    Danke
    Gruss
    Joey
    PS ich kapiers echt nicht warum ein Schlüsselfeature einfach aufgegeben wird - aber ich muss ja nicht alles kapieren

    Öhm, zu früh gefreut.
    Wenn ich den PC boote, wirft vdr nun das Fernsehbild und das LCD durcheinander, falls das Pearl angesteckt ist: das Fernsehbild ist megakomisch gestaucht, das Display bleibt leer.
    Wenn ich die (von keine_ahnung verbesserte) udev-Regel weglasse oder das display nicht anstecke beim booten, gehts. Aber ohne Regel keine LCD Anzeige...und anstöpseln nach dem Booten nervt X(
    Info: ich habe für user vdr die Gruppe uucp wieder entfernt, und benutze das main Repository. Ausserdem habe ich lcd4linux wieder deinstalliert, denn das kommt sich mit graphlcd in die quere.
    Dafür habe ich vdr zusätzlich nun der Gruppe video zugeordnet, denn sonst findet er seit dem letzten dist-upgrade (das ich dummerweise auch gestern gemacht habe) das DVB device nicht.
    Version vdr-plugin-graphlcd: 0.3.0+git20120310-0yavdr1~natty


    im syslog find ich nicht so recht die stelle, wo das schiefgeht.
    Hat jemand ne Idee, wie ich mit angestöpseltem LCD vernünftig booten kann?


    Danke