update: mcli plugin mit 2.0.3 - es läuft

HoppaZ · 16. September 2013

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

HoppaZ · 17. September 2013

Basierend auf http://ppa.launchpad.net/yavdr…1+svn20120927.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

HoppaZ · 18. September 2013

Moinsen....

der aktuelle Code hat nun hier zu finden:

http://projects.vdr-developer.org/projects/plg-mcli

Razorblade · 12. Oktober 2013

Hab nach langer Zeit mal mein NAS updaten müssen (wo der vdr läuft) und nun kommt das System mit einem Kernel 3.4 anstatt 2.6.32, so dass ich gezwungen bin auch auf das mcli-plugin umzusteigen (alternativ werde ich noch versuchen dvbloop irgendwie umzustricken, sehe aber geringe Erfolgsaussichten).
Habe nun das vdr-mcli-plugin aus dem vdr-developer git ausgecheckt, kompiliert und eingebunden.
Soweit sieht das erstmal gut aus:

Code

Oct 12 18:48:47 nas vdr: [4984] mcli: Add CAMs from NetCeiver fe80::208:54ff:fe54:da03 -> 1
Oct 12 18:48:47 nas vdr: [4984] mcli: Add Tuner: Conexant CX24116 DVB-S2 [fe80::208:54ff:fe54:da03:0400], Type 4 @ 1
Oct 12 18:48:47 nas vdr: [4984] mcli: Add Tuner: Conexant CX24116 DVB-S2 [fe80::208:54ff:fe54:da03:0401], Type 4 @ 1
Oct 12 18:48:47 nas vdr: [4984] mcli: Add Tuner: Conexant CX24116 DVB-S2 [fe80::208:54ff:fe54:da03:0402], Type 4 @ 1
Oct 12 18:48:47 nas vdr: [4984] mcli: Add Tuner: Conexant CX24116 DVB-S2 [fe80::208:54ff:fe54:da03:0404], Type 4 @ 1
Oct 12 18:48:47 nas vdr: [4984] 4 tuner available: enabling 4 devices

Code

# netcvdiag -a
Count: 1
NetCeiver 0:
  UUID <fe80::208:54ff:fe54:da03>, ALIVE, tuners 4
  OS <2.4.32-uc0>, App <0.99.34>, FW <AVR0037/FPGAC94>, HW <0055>
  Serial <33a000000yyyyyyyy>, Vendor <BayCom GmbH>, state 0
  SystemUptime 16257884, ProcessUptime 16257867
  TunerTimeout 432000
  CI-Slot 0: State <MISSING>, Mode <CA_MULTI_SID>, CAPMT-Flag: 0, SIDs 0/4, CAM <>
  CI-Slot 1: State <MISSING>, Mode <CA_MULTI_SID>, CAPMT-Flag: 0, SIDs 0/4, CAM <>
  Tuner 0: <Conexant CX24116 DVB-S2>,  SatList: <Multiswitch 1>, Preference 0
  Tuner 1: <Conexant CX24116 DVB-S2>,  SatList: <Multiswitch 1>, Preference 0
  Tuner 2: <Conexant CX24116 DVB-S2>,  SatList: <Multiswitch 1>, Preference 0
  Tuner 3: <Conexant CX24116 DVB-S2>,  SatList: <Multiswitch 1>, Preference 0


NetCeiver 0: SatList <Multiswitch 1>, entries 1
  Satname: <S19.2E>, Position <19.2E>, entries 4
    Entry 0: Polarisation V, Min 10700, Max 11700, LOF  9750 MINI_A   TONE_OFF VOLTAGE_13 DiSEqC <E0 10 38 F0>
    Entry 1: Polarisation V, Min 11701, Max 13000, LOF 10600 MINI_A   TONE_ON  VOLTAGE_13 DiSEqC <E0 10 38 F1>
    Entry 2: Polarisation H, Min 10700, Max 11700, LOF  9750 MINI_A   TONE_OFF VOLTAGE_18 DiSEqC <E0 10 38 F2>
    Entry 3: Polarisation H, Min 11701, Max 13000, LOF 10600 MINI_A   TONE_ON  VOLTAGE_18 DiSEqC <E0 10 38 F3>


UUID <fe80::208:54ff:fe54:da03>:
      slot 0.0, type DVB-S2, used:   0
      NO LOCK, frequency 12343000kHz (1744.8MHz), position <19.2E>
      strength c600, snr 0000, ber 0000, unc 0000
      NIMCurrent 76
      RotorStatus 0, RotorDiff 0.0
UUID <fe80::208:54ff:fe54:da03>:
      slot 0.1, type DVB-S2, used:   0
      LOCK   , frequency 12304000kHz (1704.2MHz), position <19.2E>
      strength e400, snr efc4, ber 0000, unc 0000
      NIMCurrent 76
      RotorStatus 0, RotorDiff 0.0
UUID <fe80::208:54ff:fe54:da03>:
      slot 1.0, type DVB-S2, used:   0
      LOCK   , frequency 12382000kHz (1782.2MHz), position <19.2E>
      strength db80, snr e9f4, ber 0000, unc 0000
      NIMCurrent 51
      RotorStatus 0, RotorDiff 0.0
UUID <fe80::208:54ff:fe54:da03>:
      slot 2.0, type DVB-S2, used:   0
      LOCK   , frequency 11836000kHz (1236.2MHz), position <19.2E>
      strength dd80, snr de54, ber 0000, unc 0000
      NIMCurrent 49
      RotorStatus 0, RotorDiff 0.0

Alles anzeigen

Allerdings sagt mit der vdr bei allen Kanälen "Kanal nicht verfügbar" es funktionieren weder Live TV noch Aufnahmen.

Muß bei der Version im GIT noch irgendwas gepatcht werden oder sind alle Patches schon angewendet? Was ist mit den VDR Patches im /patches Verzeichnis? Wenn ich mich richtig erinnere, brauchte man die doch nur für CAM-Einbindung oder?

Hat noch jemand eine Idee?

Razorblade · 13. Oktober 2013

Habe auf der Console (z.B. bei Versuch einer Aufnahme) Fehlermeldungen wie:

Code

ProvidesChannel:12 Channel:Das Erste HD, Prio:50 this->Prio:-100 m_chan.Name: NeedsDetachReceivers:0 -> 0
ProvidesChannel:9 Channel:Das Erste HD, Prio:50 this->Prio:-100 m_chan.Name: NeedsDetachReceivers:0 -> 0
ProvidesChannel:10 Channel:Das Erste HD, Prio:50 this->Prio:-100 m_chan.Name: NeedsDetachReceivers:0 -> 0
ProvidesChannel:11 Channel:Das Erste HD, Prio:50 this->Prio:-100 m_chan.Name: NeedsDetachReceivers:0 -> 0
ProvidesChannel:12 Channel:Das Erste HD, Prio:50 this->Prio:-100 m_chan.Name: NeedsDetachReceivers:0 -> 0
ProvidesChannel:9 Channel:Das Erste HD, Prio:50 this->Prio:-100 m_chan.Name: NeedsDetachReceivers:0 -> 0
ProvidesChannel:10 Channel:Das Erste HD, Prio:50 this->Prio:-100 m_chan.Name: NeedsDetachReceivers:0 -> 0
ProvidesChannel:11 Channel:Das Erste HD, Prio:50 this->Prio:-100 m_chan.Name: NeedsDetachReceivers:0 -> 0
ProvidesChannel:12 Channel:Das Erste HD, Prio:50 this->Prio:-100 m_chan.Name: NeedsDetachReceivers:0 -> 0

cetixx · 25. Oktober 2013

Vielen Dank für den Thread und vorallem an die/denjenigen, der den mcli-Treiber gepatch't hat! Ich hatte Monate lang mich nicht mehr getraut mein Gentoo upzudaten. Letzte Woche hatte ich es endlich durchgezogen (und hab nun ein topaktuelles Gentoo), nachdem ich diesen Thread gesehen habe. Der mcli-Treiber aus dem GIT-Repository http://projects.vdr-developer.org/git/vdr-plugin-mcli.git/ klappt mit dem VDR 2.0.2 aus dem Gentoo-Repo und dem Netceiver wunderbar. Einfach klonen, make, glücklich sein Sky mit Alphacrypt tut auch noch. XBMC mit XVDR oder VNSI hab ich nicht probiert, da ich kein Live-TV gugge, sondern alles nur aufzeichne und dann mit XBMC anschaue.

HoppaZ · 6. November 2013

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!

HoppaZ · 7. November 2013

cetixx:

sky mit alphacrypt bedeutet doch, daß du CAM benutzt oder?

Razorblade · 7. November 2013

Das war mit einem vanilla 2.0.2 oder 2.1.1 weiß nicht mehr genau. Gab ja auch keine Fehlermeldungen, sehr merkwürdig.
Habe inzwischen ein dediziertes System mit yavdr aufgesetzt und für den dortigen Kernel klappt noch alles mit dvbloop...

Razorblade · 1. Dezember 2013

Also es war 2.1.1 und ich habe nach wie vor das gleiche Problem.
Ich hatte zwischendurch noch vermutet, dass es ein Berechtigungsproblem ist (vdr läuft nicht als root), aber /var/tmp/mcli.sock gehört dem user vdr.

Wenn ich (vanilla) vdr nur mit mlci-plugin (wahlweise mit ohne dummydevice Plugin mangels Ausgabeplugin) starte passiert nur folgendes:

Code

# /usr/local/bin/vdr -v /share/Recordings -c /var/lib/vdr -L /usr/local/lib/vdr -E /share/Recordings/.config/epg.data -u vdr -g /tmp --port 6419 -Pdummydevice -P 'mcli --ifname eth1' --dirnames=252,252,1 -w 60 -l 3 --lirc=/dev/null
mcli: Add CAMs from NetCeiver fe80::208:54ff:fe54:da03 -> 1
mcli: Add Tuner: Conexant CX24116 DVB-S2 [fe80::208:54ff:fe54:da03:0400], Type 4 @ 1
mcli: Add Tuner: Conexant CX24116 DVB-S2 [fe80::208:54ff:fe54:da03:0401], Type 4 @ 1
mcli: Add Tuner: Conexant CX24116 DVB-S2 [fe80::208:54ff:fe54:da03:0402], Type 4 @ 1
mcli: Add Tuner: Conexant CX24116 DVB-S2 [fe80::208:54ff:fe54:da03:0404], Type 4 @ 1
cDevice::PrimaryDevice ()0xb56087d8
ProvidesChannel:10 Channel:Das Erste HD, Prio:0 this->Prio:-100 m_chan.Name: NeedsDetachReceivers:0 -> 0
ProvidesChannel:11 Channel:Das Erste HD, Prio:0 this->Prio:-100 m_chan.Name: NeedsDetachReceivers:0 -> 0
ProvidesChannel:10 Channel:Das Erste, Prio:0 this->Prio:-100 m_chan.Name: NeedsDetachReceivers:0 -> 0
ProvidesChannel:11 Channel:Das Erste, Prio:0 this->Prio:-100 m_chan.Name: NeedsDetachReceivers:0 -> 0

Alles anzeigen

Weder "Das Erste HD" noch "Das Erste" sind verfügbar. Was mich irrtiert ist "PrimaryDevice ()0xb56087d8" was steht da bei euch?

Ich habe beim Testen mit dvbloop (auf einem anderen System) festgestellt, dass neuere vdr mit teilweis integriertem S2API Patch teilweise die DVB-S2 Tuner nur als DVB-S behandelt (wegen API Änderungen FE_PROPERTIES), das dürfte doch aber bei der Verwendung des mcli-Plugins keine Rolle spielen oder?

HoppaZ · 2. Dezember 2013

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 · 2. Dezember 2013

Es scheint tatsächlich ein Problem mit vdr 2.1.x zu sein, mit 2.0.4 geht es wunderbar...

cetixx · 2. Dezember 2013

@HoppaZ: Sorry, ich hab den Thread jetzt gar nicht weiter verfolgt. Ja, "sky mit alphacrypt" bedeutet, das ich CAM benutze. Ich hatte jetzt ein paar Wochen (aber das war schon vor dem Umstieg auf VDR 2 und das neue mcli-Plugin) Probleme mit dem Aufzeichnen von Sky Programmen. Das passiert 1-2 mal im Jahr, das ich für 2-4 Wochen nur noch vereinzelt vernünftige Aufzeichnungen hinbekomme, d.h. die .ts Dateien sind dann oft nur 0 Byte groß und im Log steht nur "vdr: [9221] retrying". Irgendwie bekommt da der Netceiver Sky mit dem CAM nicht entschlüsselt und gibt dann irgendwann auf. CAM raus, CAM rein, dann geht's meistens wieder für 1-2 Sendungen und dann ist wieder Essig. Aber wie gesagt: Das war schon vor VDR 2 und dem neuen mcli-Plugin so, aber z.Zt. klappt es absolut problemlos und ich kann auch zwei Sky-Sendungen gleichzeitung aufnehmen

Bezügl.: >> ... Soweit ich verstanden läßt sich mit CAM aufnehmen... jedoch über
xvdr o.ä. kein LIVE-TV streamen. <<

Genauso ist es. Aufnehmen geht, Live-TV nicht. Dafür gibt's auch einen Grund. Das "Gute" ist bloß, das er mir nicht mehr einfällt... Das ging ganz früher mal und irgendwann dann plötzlich nicht mehr. VNSI hatte ich nie verwendet, das war schon immer XVDR bei mir, aber irgendwann hatte es im XVDR-Plugin eine Änderungen gegeben und seitdem ging das nicht mehr, soweit ich mich ganz dunkel erinnere.

HoppaZ · 3. Dezember 2013

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

gda · 3. Dezember 2013

Zitat von HoppaZ

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

Na beides.

Gerald

Razorblade · 28. Januar 2014

Konnte das mit den Problemen unter 2.1.x schon jemand reproduzieren oder gar lösen? Würde ganz gerne mal 2.1.4 testen, insbesondere das neue CAM Handling...

Edit: gerade nochmal mit 2.1.4 probiert, gleiches Problem, überall "Kanal nicht verfügbar"

Razorblade · 29. Januar 2014

Also ich bekomm das mcli Plugin (jetzt mal unabhängig von sämtlichem CAM Handling) nicht unter 2.1.4 zu laufen, verstehe aber partout nicht warum...
Bin nochmal den 2.0.0 -> 2.1.1 diff durchgegangen und das einzig fundamentale sind die diseqc Änderung bzgl Positioner. Aber selbst bei abgeschalteten diseqc funktioniert 2.1.x bei mir nicht.

Hab auch mal die Logs vergleichen, außer dass das Device-Number unter 2.1.x mit 1 (vorher mit 9) beginnt konnte ich keinen Unterschied ausmachen, sehr merkwürdig.

Darkstar · 29. Januar 2014

Hi,
ist zwar etwas OT aber gibt es irgendwo eine verständliche Dokumentation der Kommunikation zwischen Netceiver und Plugin? Ich suche gerade eine Möglichkeit SAT>IP besser als über das IPTV Plugin in VDR zu integrieren und überlege, ob man dafür das mcli-plugin vielleicht modifizieren könnte.

Gruß Darkstar.

Razorblade · 29. Januar 2014

Außer dem Sourcecode leider nicht viel, aber ich denke der umgekehrte Ansatz wäre effektiver, siehe Vorschlag: Gemeinsame Basis für netzwerkbasierte Tuner (SAT>IP, Netceiver, Octopus-Net)
Schau Dir doch mal vtuner als Beispiel an.

Moorviper · 29. Januar 2014

http://www.baycom.de/download/…netceiver_white_paper.pdf

update: mcli plugin mit 2.0.3 - es läuft

Jetzt mitmachen!

Teilen