Posts by HoppaZ

    Hi...

    mal ne Frage am Rande...


    In der Plugin Beschreibung (http://www.saunalahti.fi/~rahrenbe/vdr/satip/) steht:

    Code
    - Inverto OEM firmware 1.17.0.120 or greater recommended.
      The firmware 1.16.0.120 can be downloaded and installed
      from their webpage: http://www.inverto.tv/support/
      An update to a newer firmware should be offered afterwards.

    Ist da jetzt 1.17.0.120 oder 1.16.0.120 gemeint? Bei Inverto finde ich keine FIrmware zum Runterladen.

    Bei mir kam es immer zu PID Update Fehlern im Log, was zu Klötzchen führen kann. Bin gespannt auf die Ergebnisse.

    Ich habe nur diese Meldungen im Log gesehen:
    Jun 28 07:43:06 vdr-server vdr: [2293] SATIP: Detected 245 RTP packet errors

    aber bislang dazu keine Auswirkungen.

    Was benutzt du denn für Versionen hast du denn bei vdr / satip plugin / iplnb firmware?

    Lars

    cetixx:

    Hattest du das verschlüsselte Live-Schauen mal über streamdev ausprobiert?

    Bezüglich xvdr oder vnsi... bin ich eher leidenschaftslos... und nutze das, was openelec grad frisst ;)

    Razorblade:

    Süpi...


    Wegen der Live-Streaming-Geschichte... Ich könnte mal versuchen die Indizien zusammenzutragen. Sollte es am mcli-plugin liegen könnte sich Holger ggf der Sache mal annehmen.
    Ich weiss nicht wieviel euch daran liegt... Wir haben jedoch beide kein CAM-Zeuch im Einsatz...

    Gruß,

    Lars

    Hallo Razorblade,

    also bei mir läuft der vdr als root... Ich denke aber auch, daß es nicht das Problem sein wird.
    Aus dem Bauch raus würde ich jetzt mal auf den Kernel tippen... (ich habe irgendwas von > 3.5 im Kopf... aktuell ist es bei mir der 3.8er).
    Bei mir läuft soweit alles außer CAM (weil ich sowas aktuell nicht habe). Soweit ich verstanden läßt sich mit CAM aufnehmen... jedoch über xvdr o.ä. kein LIVE-TV streamen.

    Aber soweit sind wir ja noch nicht...

    Hier der Output meines vdrs...

    Dec 2 09:13:00 vdr-server vdr: [22570] XVDR: Recordings state changed (98)
    Dec 2 09:13:00 vdr-server vdr: [22558] mcli: Add CAMs from NetCeiver fe80::208:54ff:fe52:d82f -> 1
    Dec 2 09:13:00 vdr-server vdr: [22558] mcli: Add Tuner: Conexant CX24116 DVB-S2 [fe80::208:54ff:fe52:d82f:0400], Type 4 @ 1
    Dec 2 09:13:00 vdr-server vdr: [22558] mcli: Add Tuner: Conexant CX24116 DVB-S2 [fe80::208:54ff:fe52:d82f:0401], Type 4 @ 1
    Dec 2 09:13:00 vdr-server vdr: [22558] mcli: Add Tuner: Conexant CX24116 DVB-S2 [fe80::208:54ff:fe52:d82f:0402], Type 4 @ 1
    Dec 2 09:13:00 vdr-server vdr: [22558] mcli: Add Tuner: Conexant CX24116 DVB-S2 [fe80::208:54ff:fe52:d82f:0403], Type 4 @ 1
    Dec 2 09:13:00 vdr-server vdr: [22558] mcli: Add Tuner: Conexant CX24116 DVB-S2 [fe80::208:54ff:fe52:d82f:0404], Type 4 @ 1
    Dec 2 09:13:00 vdr-server vdr: [22558] mcli: Add Tuner: Conexant CX24116 DVB-S2 [fe80::208:54ff:fe52:d82f:0405], Type 4 @ 1
    Dec 2 09:13:00 vdr-server vdr: [22558] 6 tuner available: enabling 6 devices
    Dec 2 09:13:00 vdr-server vdr: [22558] switching to channel 1
    Dec 2 09:13:00 vdr-server vdr: [22573] receiver on device 9 thread started (pid=22541, tid=22573, prio=high)
    Dec 2 09:13:00 vdr-server vdr: [22541] switching to channel 1
    Dec 2 09:13:00 vdr-server vdr: [22575] receiver on device 10 thread started (pid=22541, tid=22575, prio=high)

    Hast du den netceiver auf einem vlan laufen bzw. bekommst du auf eth1 die Pakete des Netceivers zu sehen?
    tcpdump -i eth1 ip6

    Bei mir sieht das so aus...:
    09:40:36.922805 IP6 fe80::6e62:6dff:fe3b:31ad > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28
    09:40:36.970483 IP6 fe80::208:54ff:fe52:d82f > ff02::1: HBH ICMP6, multicast listener queryv2 [gaddr ::], length 28

    Du solltest ihn zumindest sehen...

    Razorblade:

    Sorry... das Update auf den Thread habe ich nicht mitbekommen... AUA

    Bei mir läuft es aktuell unter Ubuntu 12.04.03 LTS mit einem kernel 3.8.0-30 ohne CAM.
    Der vdr ist auf 2.0.3.

    Was für eine vdr Version hattest du denn bei dem Lauf installiert?
    Läuft es mittlerweile?

    cetixx:

    Ich bin Holger auch noch immer sehr dankbar :) Deswegen war es mir ein Anliegen es im git zu sichern... Schön zu hören, daß CAM auch geht!

    Übrigens nutze ich es mit openelec und xvdr bzw. vnsi und es rennt auch damit fein!

    Basierend auf http://ppa.launchpad.net/yavdr/testing-…927.orig.tar.gz

    und allen patches die hsteinhaus für das mcli plugin zusammengestellt hatte...

    ein kombinierter Patch inklusive Anpassung des Makefiles auf das neue Format und den letzten Aktualisierungen aus dem reel svn.

    Die einzelnen Patches habe ich in der Datei patches.zip zusammengepackt.


    Ein Zuhause auf vdr-developer.org ist bereits beantragt...

    Gruß,

    Lars

    UPDATE: Beim mergen ist mir ein fix entfleucht... ( TEMP_DISABLE_DEVICE auszukommentieren ) - Das habe ich nachgepflegt - sorry... ist abends aufgefallen.

    Servus,

    das mcli plugin läuft mit vdr 2.0.3. Leider gibt es aktuell Fehler beim Compile wenn im vdr Makefile "-Werror=overloaded-virtual" in den CXXFLAGS angegeben ist.
    hsteinhaus - dem ich noch immer sehr DANKBAR bin, daß er den letzten Patch gebaut hatte... damit das plugin wieder läuft... - meinte er könne sich das mal anschauen.

    Wie dem auch sei... Der patch den ich gebaut habe basiert auf den letzten patches... einem angepassten Makefile für 2.0.3 und einem angepassten Makefile für die Tools, da diese ansonsten sich nicht übersetzen ließen.

    Basierend auf dem letzten Stand des svns:
    svn co svn://reelbox.org/testing/src/vdr-plugins/src/mcli-1

    cd mcli-1
    patch -p0 < mcli-2.0.3-1.diff
    cd ..
    ln -s mcli-1 mcli

    und Anpassen des vdr Makefiles (-Werror=overloaded-virtual) läßt es sich bauen und funktioniert auf fein ;)

    Allen Unkenrufen zum Trotze....

    hsteinhaus hatte die Idee eines Forks. Vielleicht wäre es schön unter vdr-developers.org ein Projekt mcli einzurichten.
    Das kann ich gerne in Angriff nehmen.

    Gruß,

    Lars

    Hi,

    um nochmal auf das eingangs beschriebene Problem zurückzukommen.
    Ich habe genau das gleich Verhalten jedoch mit mehreren Tuner-Karten.
    Da ich mit Kris ein bischen hin- und her-geschrieben habe... vielleicht können wir das Problem ja doch eingrenzen...

    3 Doppel-Tuner
    vdr 1.7.21 (im lxc container ubuntu 11.10 auf ubuntu 12.04 server)
    kernel 3.2.0-24-generic
    mcli aus baycom svn (r188 oder r186)

    Der vdr läuft mit mcli plugin.

    Ich kann solange umschalten, bis 5 der 6 Tuner auf LOCK stehen. Der letzte Tuner steht immer auf NO LOCK.
    Ist das der Fall, dann kann man den netceiver per "./netcvupdate -i fe80::208:54ff:fe52:d82f -R" neu starten und das ganze geht wieder von vorne los.

    Scheinbar funktioniert das "Releasing Tuner" nicht mehr, auch wenn der vdr es an der Konsole beteuert.

    Kann sonst noch jemand irgendwas dazu beisteuern? Da Kris meinte, daß die Probleme erst ab vdr > 1.7.22 auftraten, bin ich mal auf die 1.7.21 zurück gegangen... 1.7.25 zeigt genau das gleiche Verhalten.

    Gruß,

    Lars

    Hi »gggggg«

    habe auch die Servervariante in Betrieb:

    Auf einem Mini ITX Board (E350IA-E45) mit 8GB ram habe ich alles was ich so als Rechner benötige per LXC
    in virtuelle Maschinen verbannt. Das ganze läuft aktuell mit Ubuntu oneiric.

    Den vdr habe ich mit ein paar plugins in der version 1.7.17 in Betrieb.

    ./vdr -v /var/lib/video.00 -c /var/lib/vdr -P 'mcli --mld-reporter-disable -i eth0' -P dummydevice -P live -P wirbelscan -P 'streamdev-server -r /var/lib/vdr/plugins/streamdev-server/externremux.sh' -P epgsearch -P svdrposd -P xvdr -p 4711

    Als Client im Wohnzimmer benutzen wir aktuell openelec (fertige xbmc distribution) auf einem zotac zbox ad02. Fernbedienen läßt sich das ganze per android phone. Openelec habe ich mir aus dem repo von pipelka gezogen (bei Bedarf mehr). Es läuft nahezu stabil und ist in unter 15Sekunden komplett gestartet.

    * Schneiden der Aufnahmen geht daran nicht!
    * Aufnahmen plane ich per live plugin - geht aber auch am client.
    * Schauen ist selbst auf einem Smartphone möglich
    * HDTV ist kein Problem

    Wenn du den vdr als server betreibst, dann würde ja auch auf der Client Seite ein vlc unter Windows oder sowas reichen...

    Gruß,

    Lars

    Ich habe gestern abend ein bischen getestet.

    Auf dem vdr mit streamdev server 1.7.17 (ubuntu natty) und mcli-Plugin der auf einem e350 fusion board in einem linux container läuft. Es gibt nur wenige discontinuity Fehler, die sich ansonsten nicht bemerkbar machen. Eine per live plugin eingestellte hdtv-Aufnahme bringt den vdr - wie hier beschrieben - zum Absturz.

    Was ich sehr interessant find ist die Tatsache, daß ein reel netclient (testing Stand) mit dem streamdev server zurecht kommt und auch die hdtv Programme tadellos und ohne Fehler anzeigt. Gibt es für das hd-Aufnahmeproblem keinen Patch?