Posts by yaGuru1968

    :-( Dann habe ich hier wohl den kürzesten...
    mein Atom/SSD System ist rein vom Linux her (also ab Start Logger bis zum Aktivieren der Tuner) in 8 Sekunden oben - aus dem PowerOff wohlgemerkt...


    Natürlich kommt da noch der Bios/Grub Overhead hinzu; habe ich jetzt nicht mitgezählt, da der Grub eh einen Moment wartet - damit ich eine Chance habe, evtl. das alternative Windows7 zu starten


    summa summarum deutlich unter 20 Sekunden ab Einschalten


    p.s.
    das sind noch yaVDR 0.2 Zeiten - kann sich mit 0.3 ja geändert haben

    ich frage ja nur, nicht das sich das Handling des xbmc-frontends in 0.3 komplett geändert hätte oder so... (ich hab' diesbezüglich mal was gehört)


    bin da gerade ein bisserl am Rumspielen und return-code untersuchen:
    man-o-man, der 'gute' xbmc crashed ja sogar (ret=134), wenn man ihn brav über Beenden verlässt :-/
    guckst du hier:


    Log-File sieht doch OK aus - oder fehlt da was? Jedenfalls ist xbmc anschliessend ge-crashed :-(
    (( na ja, letzte Meldung bezieht sich auf VNSI addon - vermutlich hakt das Beenden hiervon noch etwas; stürzt ja nicht immer ab ))


    <EDIT>da fehlt tatsächlich noch die allerletzte Meldung (DEBUG: PVR: destroyed) - muss wohl in den letzten Zügen noch irgendwie abgeraucht sein...

    Quote

    Original von steffen_b
    ... Mit 0.2 hatte das auch nicht soviel Sinn sich damit auseinanderzusetzen. ...

    d.h. mit yaVDR 0.3 wird Alles Gut? :rolleyes:


    Ist das Topic also jetzt (bzw. bald) gelöst oder wie oder was?
    -- sprich: macht das überhaupt Sinn, sich jetzt noch - also: 0.2 - damit auseinanderzusetzen? (wohl eher nicht - siehe Zitat...)
    Oder sollte ich bis 0.3 warten und mich dann darum kümmern (falls überhaupt noch nötig)?

    Quote

    Original von hepi
    Bitte mal das hier lesen, vielleicht erklärt das das Problem des Threadstarters:
    Shutdown bei Absturz XBMC


    Gruß
    hepi


    Dazu möchte ich fragen: von wo wird eigentlich das /usr/bin/xbmc Script aufgerufen (und auf dessen Return-Wert reagiert)?
    Ein weiteres Script oder ein Binary?
    Falls das keiner beantworten kann/will: welche Return-Werte bedeuten was? (z.B. x=shutdown, y=suspend, z=reboot, ...)

    Ich denke, dass ich ein ganz ähnliches Problem habe, denn:


    ...auch ich habe natürlich nicht die Power-Taste gedrückt! (Ich war zu dem Zeitpunkt nicht mal zuhause...)


    Ist dies ein Anzeichen/Beweis dafür, dass das xbmc FE abgestürzt ist?


    Falls nicht, WO steht denn dann "im Klartext" (SIGSEGV oder so für xbmc.bin), dass es passiert ist?


    laut /usr/bin/xbmc wird doch irgendwo ein xbmc_crashlog-<Datum/Uhrzeit> erstellt .... *wo* finde ich diese Files?
    -- oder hat das da oben (syslog) nix mit 'nem xbmc Crash zu tun?

    ich habe den Threadtitel bewusst so gewählt (und nicht: "fährt einfach 'runter" oder so), denn ich befürchte, dies hat nix mit yaVDR zu tun...


    d.h. mir ist es auch schon in der Windows-7 Session passiert - yaVDR ist als Default-Session in einer Dual-Boot Konfiguration installiert; ebenso ist der HTPC (schon mehrmals) direkt im BIOS-Menu ausgegangen.


    Was könnte dies alles sein?
    -> krumme BIOS-Settings möchte ich mal ausschliessen:
    ich habe APM komplett deaktiviert und "load failsafe defaults" gemacht - hat beides (incl./excl.) nichts gebracht; kann noch was Anderes (ACPI/AHCI und wie sie alles heissen) dazu führen, dass sich der HTPC einfach ausschaltet?
    (CPU/GPU ist aktiv gekühlt und schaltet sich auch in kaltem Zustand -- d.h. direkt nach Einschalten nach langer Aus-Phase -- schon mal direkt wieder aus... [CPU-Temp. < 50°])


    -> defektes MB? -- weiss nicht, tritt ja nicht immer auf...


    -> defektes Netzteil? -- wie kann ich das überprüfen? Alle Spannungen überwachen kann ich nicht (habe nicht so viele Messgeräte...); reicht es, eine enizelne Spannung zu überwachen?
    Falls ja, welche zu überwachen wäre sinnvoll/oder ist das egal?

    Quote

    Original von kris
    irgendwo schwirrte ja ein Howto von mir rum, wie man ein VLAN erstellt.


    ...und genau danach habe ich es auch aufgesetzt...


    allerdings steht in diesem HowTo nix darüber, WO man die VLAN Einstellungen am Besten einbaut!!!


    also - so sah mein /etc/network/interfaces gemäß deines VLAN HowTo's aus:


    ...allerdings ist folgende Variante schneller, denn hierbei muss das VLAN nicht auf das DHCP von eth0 warten:


    bringt bei mir bis zu 2 Sekunden Gewinn!
    -- damit startet mein VDR nicht erst in 8 Sekunden sondern schon in 6! Und zwar incl. funktionierendem NetCeiver

    Quote

    Original von steffen_b
    /etc/init/network-dvb.conf

    Code
    1. description "Block vdr starting, until network is done for network DVB device"
    2. author "Steffen Barszus <steffenbpunkt@gmail.com>"
    3. start on (starting vdr and started network-interface INTERFACE=eth0)
    4. stop on (stopped vdr or stopped network-interface INTERFACE=eth0)


    Wenn man net-device-up IFACE!=lo benutzen will und einen eigenen Status müsste man halt noch einen job zusätzlich definieren.


    Man lernt nie aus ;) - So in die Richtung, stelle ich mir vor das wir es einbauen können. Jetzt muss mir nur noch jemand sagen: JA DAS GEHT. Alles andere will ich nicht hören ;)


    das funktioniert leider nicht - damit bleibt er im yaVDR Splashscreen stehen und der VDR kommt nicht hoch!


    ich habe das jetzt so, damit funktioniert es, jedenfalls bei mir:


    alle anderen Varianten funktionieren entweder gar nicht oder bei einem Restart nicht...


    <update>aktuelle Variante sieht so aus:

    die VLAN Frage beantworte ich mir jetzt einfach mal selber ;-)


    nach Rückfrage diesbzgl. mit Kollegen meinten diese, ich solle den 'normalen' (sprich ETH0) Zugriff halt auch über das VLAN machen - ETH0.1 in diesem Fall...


    Also gar nix mehr direkt über ETH0, sondern: ETH0.1 für WebI/F und so'n Zeug u. ETH0.2 für NetCeiver...


    Da die beiden VLANs zwar beide von ETH0 abhängig sind, aber untereinander keine Abhängigkeiten bestehen, braucht der NetCeiver an ETH0.2 nicht auf das dhcp vom ETH0.1 warten


    Hört sich für mich schlüssig an, werde ich mal testen
    -- fragt sich nur, was ich alles ändern muss, damit z.B. das WebI/F über ETH0.1 anstelle von ETH0 läuft?? (hier sind jetzt die yaVDR Experten gefragt ;-)

    Sieht gut aus, werde ich heute Abend / am Wochenende testen!


    das Ändern der vdr.conf hat mir selber auch nicht gefallen, ist nicht generell zu gebrauchen...
    --> dieses Upstart-Script dürfte dann aber nur mit Installation des NetCeiver Plugins bzw. anderer Netzwerk-DVB-Devices installiert werden, oder?



    mal eine etwas OT Frage bzgl. VLAN:
    mein ETH0 ist z.Zt. auf dhcp und ETH0.2 ist statisch - kommt allerdings in der Reihenfolge nach ETH0 (/etc/network/interfaces)


    kann ich einfach den ETH0.2 Eintrag VOR den ETH0 Eintrag setzen, oder muss ETH0 UP sein, damit das ETH0.2 überhaupt erst gestartet wird?
    --> vermutlich schon, oder? das ETH0 ist ja quasi die physikalische Schnittstelle übder die das virtuelle ETH0.2 kommuniziert...
    --> benötigt es dazu aber eine gültige Netzwerk-Adresse auf ETH0 - sprich: muss ETH0.2 wirklich warten, bis auf ETH0 eine IP-Adresse via dhcp verfügbar ist, eigentlich doch nicht?


    Also folgende Reihenfolge:
    ETH0 UP
    ETH0.2 UP ADDRESS=x.x.x.x ...
    ETH0 DHCP
    -> damit sollte das VLAN theoretisch schneller da sein, geht aber vermutlich nicht???

    DANKE!


    ich habe (innerhalb von /etc/init/vdr.conf) aus dem

    Code
    1. start on local-filesystems


    Folgendes gemacht:

    Code
    1. start on (local-filesystems and net-device-up IFACE=eth0.2)


    (der NetCeiver hängt an VLAN eth0.2)


    damit funktioniert es jetzt direkt nach dem Booten!


    (mit 'ner eigenen NetCeiver.conf habe ich auch gespielt, hat aber nicht funktioniert...

    Code
    1. script
    2. until dmesg | grep 802.1Q VLAN ; do sleep 1 ; end
    3. end script


    -- ich dachte diese Meldung kommt erst, wenn das VLAN Interface up ist, kommt zeitlich jedenfalls nach dem "link up" des physikalischen Interfaces... evtl. doch noch zu früh?
    )



    jetzt muss ich mich doch noch mit Templates beschäftigen, damit das nach dem nächsten dist-upgrade auch noch drinnen ist ;-)



    p.s.
    ich habe allerdings immer noch das GROSSE Problem, dass meine Kiste einfach so aus heiterem Himmel einfach aus geht :-(
    -- aber dies soll ein anderer Thread sein (ich habe letztens so ziemlich alle LifeGuard Settings auskommentiert, weil er eigentlich NIE ausging wenn er sollte - nun geht er immer dann aus, wenn er WILL; wahrscheinlich so was wie die Rache vom LifeGuard...)


    p.p.s.
    die Zeit bis zur Anzeige des Frontends (bei mir XBMC) ist nun DEUTLICH länger - ich sehe sogar vorher noch das yaVDR Logo!
    -- aber das wird wahrscheinlich am dhcp liegen; nächster Halt: statische IP-Adresse...

    diese mcli/dvbloop Daemons waren vor dem vdr-plugin-mcli notwendig für den NetCeiver Betrieb.


    Die Frage ist nun, läuft das immer noch so (also mcli/dvbloop anstelle von vdr-plugin-mcli) oder darf ich diese Beiden nur zur Detektion des NetCeivers verwenden und muss sie danach killen (damit das plugin läuft), oder wie oder was?



    Die eigentliche Frage ist aber (nach wie vor): wiese bedarf es eines VDR-Restarts, damit der NetCeiver erkannt wird und funktioniert?
    - in den Logs ist mir auf den ersten BLick kein Fehler aufgefallen: dort steht, dass das mcli-plugin gestartet wurde, Versions-Nummer etc. - aber nicht mehr (keine gefundenen Tuner vom NetCeiver, keine Kanäle etc.) -- allerdings auch keine explizite Fehlermeldung


    im "Gut-Fall" (also nach manuellem Restart) steht das auch genauso dort drinnen - allerdings noch zusätzlich, dass halt 4 Conexant Tuner (oder so) gefunden wurden (mit Versions-Nummer etc.) und die Kanäle etc.


    Der Schlecht-Fall sieht einfach so aus, als ob der mcli zwar gestartet wird aber nicht funktioniert...


    (ich kann ja nach Feierabend mal die relevanten Infos aus den beiden Fällen hier anhängen)


    p.s.
    zum netcvdiag: ich denke das ist einfach ein Tool zur Diagnose des gesamten Empfangspfads und nicht zur Analyse, ob ein NetCeiver vorhanden ist - sprich: es zeigt nur etwas an, wenn NetCeiver PLUS die ganzen zusätzlichen Software-Teile zusammen funktionieren...

    allerdings funktioniert netcvdiag nur, wenn mcli läuft...


    konkret:


    "stop vdr" -> netcvdiag zeigt keinen NetCeiver an
    "start vdr" -> netcvdiag zeigt ihn an


    bin mir hier nicht so sicher, ob ich netcvdiag als DOSOMETHING verwenden könnte
    (kann ich das mcli-plugin ohne VDR starten? falls ja, wie?)


    vermutlich komme ich hier nur mit einem ping6 weiter, habe aber damit noch keine Erfahrung
    -- ausserdem nicht ganz so flexibel, da ich auf die spezielle IPv6 Adresse des NetCeiver prüfen müsste ( also nix für den generellen Gebrauch... )

    ja, genau sowas in der Richtung war das!


    ich habe keine Ahnnung, wer da auf was warten muss - das Problem ist auch "neu" bei mir, ursprünglich brauchte ich sowas nicht... aber jetzt scheint es nicht mehr ohne zu gehen!


    Frage mich jetzt bitte nicht, warum so plötzlich - ausser ein paar mal "apt-get --reinstall install vdr-plugin-mcli" (da ich generell Probleme damit hatte - Ruckeln, nur wenige Kanäle wurden angezeigt, etc.) habe ich nämlich komplett die Finger vom System gelassen; Fast: im Bios bin ich noch mal auf "Load Failsafe Defaults" gegangen, weil die Kiste sich von selber aus heiterem Himmel ausgeschaltet hatte... ...einen neuen Lüfter musste ich einbauen... ...und den NetCeiver selber habe ich zwischendurch einmal re-bootet, aber sonst ehrlich nichts installiert/de-installiert...


    ich weiss nicht, ob der VDR das Problem ist - ich denke eher, dass der mcli das Problem ist, also müsste das Starten des mcli verzögert werden, vermutlich bis das Netzwerk da ist, da könntest du schon recht haben...


    Aber wie soll ich im DOSOMETHING überprüfen, ob der NetCeiver da ist?
    "netcvdiag" funktioniert ja noch nicht (d.h. ohne gestarteten vdr-mit-mcli-plugin)?


    vielleicht ein ping6 oder sowas??? hmmm... mal (ver)suchen...



    p.s.
    wo muss ich dieses Script einbauen?

    Hi,


    ich habe das Problem, dass mein NetCeiver direkt aus dem Booten heraus nicht erkannt wird ('netcvdiag -a' zeigt 'count: 0' ; keine Kanäle funktionieren).
    wenn ich nun (per Konsole/ssh) ein 'sudo stop vdr; sudo start vdr' aufrufe, dann funktioniert es...


    Ich habe hier im Forum mal beim Posting-Zappen einen entsprechenden Beitrag dazu gelesen, aber ich finde den nicht mehr und die Suche danach ergibt auch nichts - mir fallen bald keine Keywörter mehr ein, nach denen ich noch suchen könnte :-(


    ..in besagtem Posting ging es darum, den VDR-Start zu verzögern, bis mcli gestartet ist oder den mcli-start zu verzögern, bis xyz gestartet ist oder sowas in der Richtung; jedenfalls ging es dort um Timing-Abhängigkeiten beim Booten -- ich denke, dass genau dies die Lösung meines Problems wäre!
    aber, wie Eingangs erwähnt: ich finde das besagte Posting nicht mehr :-((


    kann mir hier bitte einer weiterhelfen?



    Danke
    yaGuru

    Quote

    Original von uwe-beach
    /file-server.00 -fstype=nfs,hard,intr,nodev,nosuid,nonstrict,async /file-server:/video


    hmm - ist dort nicht ein '/' zu viel??


    also eher so:
    file-server.00 -fstype=nfs,hard,intr,nodev,nosuid,nonstrict,async /file-server:/video


    versuche das mal...
    (alternativ: versuche die IP-Adresse statt des DNS-Namens)

    after selecting the xbmc you additionally have to activate the proper add-on within xbmc to actually get Live-TV:


    System -> Add-ons -> Installed Add-ons -> PVR Client -> PVRClient for streamdev
    or
    System -> Add-ons -> Installed Add-ons -> PVR Client -> VSNI (<-- should be more stable)


    after activating one of those add-ons, Live-TV should work instantaneously...

    bei mir hat ein dist-upgrade bisher jedenfalls nie wirklich funktioniert, nach den diversen Neu-Installationen funktioniert es allerdings sehr wohl... soviel dazu!
    - ich würde selbstverständlich sehr gerne auf die Neu-Installation verzichten, allerdings schwindet die Hoffnung darauf täglich mehr


    zu bluez-utils: die Installation von bluez ging ansich ohne Probleme - allerdings habe ich das nicht alleine getestet sondern direkt im Anschluss bluez-utils installiert; das bluez-utils Paket umfasst sage-und-schreibe 97MB, inclusive ghostscript und jede Menge Postscript-Fonts (vermutlich nur benötigt um die tollen grafischen Konfig-Tools a la blueman etc. anzuzeigen!?)
    Jedenfalls hatte ich nach der Installation von bluez / bluez-utils gar kein Bild (XBMC) bzw. No-Signal in einem der anderen Front-Ends (das Web-UI lief zum Glück noch und somit konnte ich umschalten).
    --> wie das nun den VDR Start (bzw. XBMC-VDR Start; denn der reine Xine VDR lief ja noch) verhindert hat, kann ich nur spekulieren (neuere Versionen von bestimmten Libs, die nicht kompatibel sind mit bestehenden Versionen von anderen Libs z.B.); da wisst ihr von yaVDR Team sicherlich besser, was schiefgehen kann...


    Nach dem dist-upgrade hatte ich zwar wieder ein XBMC-Bild (solche Library-Inkompatibilitäten werden ja hierdurch beseitig, spricht also für meine Spekulation), allerdings noch immer keine Kanäle (bzw. ein paar wenige, die nicht flüssig dargestellt werden) --> Ich würde (fast) wetten, dass ich nach eine Neu-Installation wieder einen lauffähigen VDR hinbekomme...
    --> Natürlich kann ich mich auch täuschen; vielleicht hängt/spinnt ja auch der NetCeiver und ich müsste ihn einfach nur Rebooten (<-- das ist der schnellste Test, werde ich mal im Auge behalten)


    Aber das eilt nicht (der neue Fernseher hat eingebauten Sat-HD-Receiver und so fernseh-versessen bin ich auch nicht) und somit kann ich noch ein wenig herumspielen, Logs auslesen etc.


    In welchen Logs muss ich denn gezielt nach VDR Fehlermeldungen suchen, bitte?


    p.s.
    da mir das dist-upgrade sowieso mein Video-Quellen im XBMC gelöscht hat und ich sonst noch nicht soviel Eigenes in der yaVDR Partition drinnen habe, tut eine Neuinstallation (noch...) nicht wirklich weh und dauert auch nur rund 25Minuten (eine 'krumme' Installation wieder geradezubiegen dauert erheblich länger als das...)