Beiträge von Nano

  • VDR auf Vu+ STBs (z.B. Vu+ Zero, SoloSE)

    Concerning the translation: Please try this first.
    Concerning the output plugin for the Vu+ DVB HW: OSD is broken and distorted. Viewing Video+Audio+Teletext and EPG is working. Currently I have not dealt with any encrypted channels as I do not own any smartcard.


    I have setup some repos on Github which contain basically the stuff from openvuplus repos plus fixes. Mainly changed URLs or missing recipes for VDR compilation.
    The main repo "openvuplus-vdr" also contains the VDR layer which I have taken from realglotzi.
    Please look here for the recipes that are already working.


    Code
    git clone https://github.com/nanosonde/openvuplus-vdr
cd openvuplus-vdr
make


    See "make help" to see the options. "make image" will build an image that can be flashed onto the box using the USB method (UNTESTED!).


    If you want try the newly compiled VDR packages on a recent image (VTI team image 7.x), simply copy the IPK files from this dir onto the box: "openvuplus-vdr/build/vusolose/tmp/deploy/ipk/mips32el"


    If you want to rebuild just a single recipe, do this first (in my case for the Vu+ SoloSE):

    Code
    cd build/vusolose
source bitbake.env


    To build a recipe:

    Code
    bitbake vdr-plugin-satip


    To clean up the recipe:

    Code
    bitbake -c cleanall vdr-plugin-satip


    The working directory for the VDR recipes can be found here: "openvuplus-vdr/build/vusolose/tmp/work/mips32el-oe-linux"


    You can also try just to download the source and extract it into the working directory:

    Code
    bitbake -c fetch vdr-plugin-satip

  • VDR auf Vu+ STBs (z.B. Vu+ Zero, SoloSE)

    Zitat von murroluppo

    Vielen Dank!
    habe bei mit bis jetzt immer openatv ohne Probleme übersetzt.
    Bei openvuplus bekomme ich nun eine fehlermeldung vom tar :rolleyes:
    Wie hast du das hinbekommen?

    DEN Fehler habe ich bisher noch nicht gehabt.
    Ich werde mal ein Image für die Vu+ Duo2 bauen lassen. Vielleicht kommt der Fehler dann bei mir ja auch.


    Es kann leider schonmal sein, dass ein Recipe nicht funktioniert. Meistens liegt es aber dann daran, dass die Download-URL nicht mehr funktioniert (Beispiel: libdaemon-0.14).
    Oder aber ein Database-File gezogen wird und die Prüfsumme nicht mehr stimmt(Stichwort hddtemp).


    Welchen Kernel und welche DVB-Modul-Version setzt denn openatv für die Vu+ STBs ein?
    Eigentlich müsste es ja damit genausogut gehen, wenn es ein aktuelles OE-Image ist.

  • VDR auf Vu+ STBs (z.B. Vu+ Zero, SoloSE)

    Zitat von murroluppo

    Könntest du mir auch deine recipes geben, mit denen du die ipk erstellt hast, dann könnte ich da selbst mal etwas rumprobieren...

    Im Anhang findest Du das entsprechende Layer.


    Sieht bei mir dann so aus:

    Code
    drwxr-xr-x  8 1000 1000 4096 Okt  2 12:58 bitbake
drwxr-xr-x  3 1000 1000 4096 Okt  2 13:11 build
-rw-r--r--  1 1000 1000 7945 Nov 27 14:52 Makefile
drwxr-xr-x 11 1000 1000 4096 Nov 21 13:44 meta-bsp
drwxr-xr-x 11 1000 1000 4096 Okt  2 13:00 meta-openembedded
drwxr-xr-x 12 1000 1000 4096 Okt  2 12:57 meta-openvuplus
drwxr-xr-x  4 1000 1000 4096 Nov 28 14:31 meta-vdr
drwxr-xr-x  7 1000 1000 4096 Okt  2 13:11 openembedded-core
drwxr-xr-x  3 1000 1000 4096 Okt  2 14:13 resource


    Makefile wie folgt angepasst:

    Code
    BBLAYERS ?= \
    	$(CURDIR)/meta-bsp/$(MACHINE) \
    	$(CURDIR)/meta-bsp/common \
    	$(CURDIR)/meta-openvuplus \
    	$(CURDIR)/meta-vdr \
    	$(CURDIR)/meta-openembedded/meta-oe \
    	$(CURDIR)/openembedded-core/meta


    Dann noch ein "make clean", damit die ganzen Bitbake Config-files neu geschrieben werden und das VDR Layer berücksichtigt wird.

  • VDR auf Vu+ STBs (z.B. Vu+ Zero, SoloSE)

    Hi!


    Ich habe die Pakete mal hier hinterlegt.
    Einfach mit "opkg install" installieren.


    Du solltest direkt das Ausgabe-Plugin und das remote-Plugin einbinden.


    Für das remote-Plugin muss ich bei der SoloSE dieses InputEvent-Device benutzen: /dev/input/event0
    Die remote.conf sieht so aus bei mir (habe mir noch keine Gedanken macht, wo genau was sein soll):


    Wichtig ist natürlich noch, dass Enigma2 vorher gestoppt wird.
    Zum Beispiel mit "init 4". Aktivierung von Enigma2 dann wieder mit "init 3".


    Ich nutze auf beiden Boxen (Duo2 und SoloSE) bei mir das aktuelle VTI Image.
    Die Pakete aus der Dropbox sind alle mit Hilfe des aktuellen GIT-Repositorys

  • VDR auf Vu+ STBs (z.B. Vu+ Zero, SoloSE)

    Mhmm. Ich dachte, dass sich dafür mehr Leute interessieren würden.
    Ich werde den aktuellen Stand des Ausgabe-Plugins mal packen und hier anhängen.


    Bis auf Weiteres werde ich aber nicht weiter daran arbeiten.


    UPDATE:
    Anhänge eingefügt.
    1) OE Recipe inkl. Ausgabe-Plugin VU+ STBs
    2) OE Recipe inkl. vtuner Kernel-Modul (wird nicht benötigt, hatte es aber noch rumfliegen)

  • VDR auf Vu+ STBs (z.B. Vu+ Zero, SoloSE)

    Zitat von glotzipapa

    Die Hardware finde ich jetzt nicht so interessant, für den Preis finde ich die CPU zu lahm und den Onboard Tuner brauche ich auch nicht. Aber VDR mit Openembedded würde mich interessieren, da ich das auf meinen Raspis benutze. Guck mal hier:

    Ok. Ich habe eine SoloSE hier. Ich frage mich, ob man die auch ohne Tuner bekommen könnte. Ist ja ein Wechseltuner. Kostet mit Tuner 199EUR. Ohne Tuner vielleicht 50EUR weniger?!
    Dort hättest Du dann einen MIPS Dualcore mit 2x1300MHz und sogar eSATA.


    Zitat von glotzipapa

    https://github.com/realglotzi/meta-av-ex…ter/recipes-vdr

    Danke für den Tipp. Sieht sehr interessant aus. Alle Rezepte schon da. :)

  • VDR auf Vu+ STBs (z.B. Vu+ Zero, SoloSE)

    Hallo zusammen,


    ich wollte mal fragen, ob Interesse an "VDR auf einem Vu+ Zero " besteht? Prinzipiell wäre natürlich vermutlich jede Box möglich, die von OpenVuplus [LINK] unterstützt wird.
    Die neue Kiste gibt es nämlich schon für 119EUR und erscheint im Dezember 2014.
    Man bekommt eine MIPS-Hardware mit Gehäuse, IR-Fernbedienung und einem nicht-wechselbaren DVB-S2 Tuner.


    Der einzige mehr und minder große Haken ist, dass die DVB-Module "closed-source" sind, aber mit der DVB API Version 5.10 auf dem aktuellen Stand sind.
    Der kernel ist aktuell die Version 3.13.5.


    Derzeit habe ich den VDR schon auf meiner Vu+ SoloSE Kiste laufen. Die IR-Fernbedienung funktioniert mit Hilfe des remote-Plugins auch schon, da sie über das Linux Input Event System läuft.
    Video, Audio [auch lauter/leister/mute] und schnelles Umschalten zwischen den Kanälen (SD und HD) funktionieren schon sehr gut.


    Das Ausgabe-Plugin orientiert sich an diversen anderen Ausgabe-Plugins. Hauptsächlich an dem dvbsddevice- und dvbhddevice-Plugin für die Einbindung der DVB API ohne OSD.
    Das OSD läuft über den Linux-Framebuffer. Das funktioniert leider noch nicht richtig und die Darstellung ist verzehrt.
    Hier könnte ich noch Unterstützung gebrauchen. Aktuell bediene ich mich hier an den Enigma2-Sourcen aus dem GIT Repository auf code.vuplus.com.


    Wenn das Ausgabe-Plugin läuft, werde ich als nächstes das satip-Plugin und das streamdev-Plugin testen.


    Zum Aufbau der Entwicklungsungebung, sollte man hiermit anfangen:
    http://code.vuplus.com/ov-quick-start.html


    Alles rund um den VDR wird dann als zusätzliches Layer bei bitbake mit eingebunden. Das habe ich noch nicht veröffentlicht.
    Meine bisherige Arbeit basiert hierauf: https://github.com/seife/meta-vdr und hierauf: http://www.egal-vdr.de/ufs910/…9xx-0.0.3pre-20100613.tgz


    Wie schaut's aus? :D


    Gruß
    Nano

  • SAT>IP Plugin und Fritz!WLAN Repeater DVB-C

    Thanks so far for your support.


    Attached you will find a working patch for the satip plugin 0.3.3 that works with the Fritzdvbc device.
    It would be nice if you could review the method cSatipServers::NumProvidedSystems(void) again for DVB-C.


    In addition to your enum eSatipQuirkPlayPids I have added the enum eSatipQuirkForceLock which is set if a "fritzdvbc" is found.
    It forces the methods SignalStrength(), SignalQuality() and HasLock() to return hardcoded values since RTCP 204 is missing.


    I have added a small piece of code in UpdatePids() which adds a dummy PID of 100 to the URI if the eSatipQuirkPlayPids is set.
    This prevents the SAT>IP server on the Fritzdvbc device from misbehaving if only PIDs <=20 are specified on the URL (example: pids=0,16,17,18,20).
    So far I can tell that it works. I do not really know what the intention on this was from AVM.


    I have tested the patch against several different channels on different transponders so far and it seems to work.


    Emails to the AVM support have been written to bring up the issues and I hope that they will fix them.

  • SAT>IP Plugin und Fritz!WLAN Repeater DVB-C

    New summary of found quirks:


    1) No RTCP packet type 204
    Problem:
    The SAT>IP specification specifies the delivery of RTCP packets together with the RTP packets. Those RTCP packets of type 204 contain the status information of the associated stream.
    Exampe: ver1.0;src=1; tuner1,240,1,7,112,,dvbc,,,,6900,34;pids=0,16,17,18,20
    This also includes the status information (e.g. signal quality, lock status, etc.) of the tuner.
    Fritzdvbc is does not deliver this kind of packets. The SAT>IP plugin cannot provide status info to VDR.
    Workaround:
    Until AVM fixes this, two options are possible:
    1a) hard-code some dummy information and always deliver the lock status (easy to implement)
    1b) Send RTSP DESCRIBE request for the stream on a regular interval to get the SDP record and extract the status info from there. (more complex to implement)
    Remark:
    Fritzdvbc only sends RTCP packet types 200 and 201: sender and receiver reports.
    Strange: Why does it send a receiver report to the client?! The receiver report is supposed to be send by the client to server.


    2) No addpids/delpids parameter support
    Problem:
    The SAT>IP specification specifies the mandatory parameters addpids/delpids to modify the table of delivered PIDs (delta-updates).
    However, Fritzdvbc does not seem to support these parameters. The parameters are accepted (RTSP status code 200), but they have no effect.
    Workaround:
    Do not use delta-updates with addpids/delpids parameters. Only use full updates with the "pids" parameter.


    3) PIDs <=20 cannot be delivered if only PIDs <=20 are specified in the "pids" parameter
    Problem:
    The SAT>IP specification specifies that PIDs from 0-8191 should be deliverable by specifying them with "pids" parameter. This would also include the case "pids=0".
    However, Fritzdvbc does not deliver PIDs <=20, when no other PID that is really present in the stream is specified additionally. It issues an internal server error instead.
    Not working examples: pids=0,16,17,18,20 // pids=0 // pids=20
    Working examples for stream "ZDF SD" (PID100 is PMT): pids=0,16,17,18,20,100 // pids=0,100 // pids=0,21 (<- SETUP-Request returns code 200 (OK), the PID 21 is not used and so a delayed PLAY-Request result in code 454 (Unknown stream))
    Workaround:
    Only send the RTSP PLAY-request until all the required PIDs have been collected. As a consequence, dynamic channel updates only work if there are already some working channels.conf entries with th correct PID settings.
    Make sure that "pids=" parameter does not only contain PIDs <=20.
    Remark:
    This should really be fixed/changed by AVM



    Please also note the second update here: SAT>IP Plugin und Fritz!WLAN Repeater DVB-C
    So the PLAY-Request may omit the "pids=" parameter if it was already used in the SETUP request to specifiy the PIDs.

  • SAT>IP Plugin und Fritz!WLAN Repeater DVB-C

    ""

    Zitat von rofafor

    So, the attached patch should add necessary quirks, but "pids=0", that's basicly a hard requirement if you want to adapt dynamically to any pid changes. I guess VLC is relying 100% to the channels.conf and doesn't use it as a starting point as VDR (Setup/Update Pids).

    Thanks, I will try that. That "pids=0" is required for the PAT and therefore for dynamic updates is clear.
    The problem with Fritzdvbc is that only specifiying "pids=0" leads to an internal server error. I assume because of a bug, because the whole SAT>IP server service does not work anymore after specifiying it. The webpage does not show the live-status anymore. A reboot is required.
    This is wrong: If you specifiy an additional dummy PID (e.g."pids=0, 16") then the PAT is delivered together with the other PID.
    Correct: Specifying only PIDs <=20 will produce the internal server error. Example: pids=0,16,17,18,20
    Setting a dummy PID for which no packets are delivered, will also result in no delivery of the PID0 (PAT).



    One more thing. Isn't this modification missing in your patch?



    Zitat von rofafor

    You'll have to notice that the Fritz!WLAN Repeater DVB-C isn't a real/certified/whatever SAT>IP device as the actual spec doesn't have the cable support yet.

    AVM claims that the product is compatible to the SAT-IP-Standard (Cenelec prEN 50585):
    http://avm.de/aktuelles/neues-…fritzwlan-repeater-dvb-c/


    The new iOS app version of Fritz!TV now also offers the option to show the internal log.
    In the log output it also states "SAT>IP server".


    I have written a couple to emails to the AVM support already. I have linked this thread for technical details. Now I hope that they consider fixing the issues in their SAT>IP server implementation.


    UPDATE1: Please see above for a minor correction concerning the acceptable "pids" parameter values.

  • SAT>IP Plugin und Fritz!WLAN Repeater DVB-C

    Hallo zusammen,


    ich habe basierend auf diesem Code hier ein kleines Test-Tool zusammengebaut, was die verschiedenen URL-Möglichkeiten ausprobiert.


    Fazit:
    * Der Fritzdvbc liefert bei addpids/delpids zwar keinen Fehler, wenn sie im PLAY-Request verwendet werden, sind aber offenbar ohne Funktion. :(
    * Die aktuelle Firmware des Fritzdvbc erwartet beim PLAY-Request immer den "pids=" parameter, sonst gibt es einen "Internal Server Error".
    * "pids=0" alleine funktioniert auch nicht, dann gibt es ebenfalls einen "Internal Server Error".
    * "pids=all" wird nicht unterstützt


    Schade!


    UPDATE1:
    Entfernt: "* das komplette Neusetzen der PIDs mit einem späteren PLAY-Request bleibt ohne Wirkung"
    Nach Neustart des Fritzdvbc funktioniert es.


    UPDATE2:
    Korrektur: "erwartet beim PLAY-Request immer den "pids=" parameter": das ist nur zwingend notwendig, wenn beim SETUP-Request kein "pids" Parameter vorhanden war.

  • SAT>IP Plugin und Fritz!WLAN Repeater DVB-C

    Noch was. Das Plugin generiert ja zunächst einen SETUP request ohne PIDs:



    Dieser wird korrekt beantwortet:


    Dann folgt später nach zwei OPTION requests der PLAY request:

    Code
    0x0030:  0f66 519b 504c 4159 2072 7473 703a 2f2f  .fQ.PLAY.rtsp://
	0x0040:  3139 322e 3136 382e 3130 2e34 2f73 7472  192.168.10.4/str
	0x0050:  6561 6d3d 3332 353f 6164 6470 6964 733d  eam=325?addpids=
	0x0060:  3131 302c 3132 302c 3132 312c 3132 3520  110,120,121,125.
	0x0070:  5254 5350 2f31 2e30 0d0a 4353 6571 3a20  RTSP/1.0..CSeq:.
	0x0080:  350d 0a53 6573 7369 6f6e 3a20 3332 350d  5..Session:.325.
	0x0090:  0a55 7365 722d 4167 656e 743a 2076 6472  .User-Agent:.vdr
	0x00a0:  2d73 6174 6970 2f30 2e33 2e33 2028 6465  -satip/0.3.3.(de
	0x00b0:  7669 6365 2030 290d 0a0d 0a          	vice.0)....


    Hier gibt es dann das Problem:


    Code
    0x0030:  0076 0a13 5254 5350 2f31 2e30 2035 3030  .v..RTSP/1.0.500
	0x0040:  2049 6e74 6572 6e61 6c20 5365 7276 6572  .Internal.Server
	0x0050:  2045 7272 6f72 0d0a 4353 6571 3a20 350d  .Error..CSeq:.5.
	0x0060:  0a53 6573 7369 6f6e 3a20 3332 350d 0a52  .Session:.325..R
	0x0070:  5450 2d49 6e66 6f3a 2075 726c 3d72 7473  TP-Info:.url=rts
	0x0080:  703a 2f2f 3139 322e 3136 382e 3130 2e34  p://192.168.10.4
	0x0090:  2f73 7472 6561 6d3d 3332 353f 6164 6470  /stream=325?addp
	0x00a0:  6964 733d 3131 302c 3132 302c 3132 312c  ids=110,120,121,
	0x00b0:  3132 350d 0a0d 0a                    	125....


    Ich befürchte, dass der SAT>IP Server auf dem Fritz-DVBC wirklich kaum etwas vom Standard vernünftig unterstützt.
    Hier vermute ich, dass er schlichtweg addpids und delpids nicht unterstützt. :(


    Das muss ich noch überprüfen.

  • SAT>IP Plugin und Fritz!WLAN Repeater DVB-C

    Ich denke, dass ich den Fehler im satip-Plugin gefunden habe.
    Den Hinweis gab der folgende Log-Eintrag:

    Code
    cSatipDevice::SetChannelDevice(0): no suitable server found


    Die Variable modelTypeM wird in

    Code
    cSatipServer::cSatipServer()

    zunächst auf eSatipModelTypeNone gesetzt.
    Hier wird anhand der Modellbezeichnungen geprüft, wie modelTypeM gesetzt werden muss.


    Für DVB-C ist bisher nur eine Sonderlösung bzgl. Octopus net enthalten, die aber den AVM Fritz!WLAN Repeater DVB-C nicht erkennt.
    Daher bleibt die Variable modelTypeM auf

    Code
    eSatipModelTypeNone

    .


    Später, wenn dann innerhalb von

    Code
    cSatipDevice::SetChannelDevice

    ein passender SAT>IP Server gesucht werden soll, liefert die Methode

    Code
    cSatipServers::Find()

    immer NULL zurück, da
    DVB-C angefordert ist, aber kein Server mit DVB-C in der Liste mit erkannten SAT>IP Servern vermerkt ist.


    Habe jetzt folgendes eingefügt:


    server.c:

    Code
    enum eSatipModule {
	eSatipModuleDVBS2 = 0,
	eSatipModuleDVBT,
	eSatipModuleDVBT2,
	eSatipModuleDVBC,
	eSatipModuleCount
  };


    Code
    if (strstr(r, "DVBC")) {
       	modelTypeM |= cSatipServer::eSatipModelTypeDVBC;
       	if (char *c = strstr(r, "-"))
          	modelCountM[eSatipModuleDVBC] = atoi(++c);
       	else
          	modelCountM[eSatipModuleDVBC] = 1;



    server.h

    Code
    //  int Cable()           	{ return Match(eSatipModelTypeDVBC)  ? (Match(eSatipModelTypeDVBT2) ? modelCountM[eSatipModuleDVBT2] : modelCountM[eSatipModuleDVBT]) : 0; } // an ugly hack
  int Cable()           	{ return Match(eSatipModelTypeDVBC)  ? modelCountM[eSatipModuleDVBC]  : 0; }



    Jetzt wird endlich der RTSP-Request ausgelöst. Dieser sieht laut tcpdump auch gut aus. Aber es bleibt nur beim RTSP SETUP. Ein RTSP PLAY kommt nicht.