Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - warp10

16
Raspberry PI / MLD 5.3 -- Kodi
« on: August 15, 2017, 22:00:01 »
Hallo nochmal,

ich hab das gerade mal ausprobiert nach der Anleitung von hape. Abweichend habe ich nicht das libreelec 8.0.1 Image verwendet, sondern 8.0.2.
Leider klappt es nicht.

Beim Starten von kodi erscheint kurz der kodi "Splashscreen" und dann steht "kodi exits at (uhrzeit)"

Das sagt die log /var/log/kodi

Code: [Select]
Segmentation fault
Illegal instruction
Illegal instruction
Illegal instruction
Illegal instruction
Illegal instruction
Segmentation fault

Den crashlog hab ich angehängt.

Hat jemand eine Idee?
Danke und Gruß,
Thorsten

17
Raspberry PI / MLD 5.3 -- Kodi
« on: August 15, 2017, 12:32:28 »
Hallo zusammen,

da der letzte Post ja jetzt bereits 2,5 Monate alt ist wollte ich mich mal nach dem aktuellen Stand erkundigen.
Ist dieses Jahr noch mit einem funktionierenden kodi für 5.3 stable zu rechnen? (ohne den Umweg über die libreelec binaries)

Danke und viele Grüße,
Thorsten

18
Hi Michael,

ja so mache ich es im Moment:

Mein aktueller Workaround: Ich programmiere zu jeder Aufnahme eine kurze Aufnahme (1 Minute) auf einem anderen Transponder, damit der TechniRouter aufwacht. Das ist natürlich ziemlich nervig.

Das lässt sich vermutlich mittels cronjob und Skript auch automatisieren. Aber irgendwie unbefriedigend.

Ich habe gesehen, dass minisatip5, dass ja auf dem Digibit läuft, die Angabe von diseqc-timings erlaubt (Quelle: https://github.com/catalinii/minisatip):
Code: [Select]
-q --diseqc-timing ADAPTER1:BEFORE_CMD1-AFTER_CMD1-AFTER_REPEATED_CMD1-AFTER_SWITCH1-AFTER_BURST1-AFTER_TONE1[,...]

    All timing values are in ms, default adapter values are: 15-54-15-15-15-0
    note: * as adapter means apply to all adapters
Vielleicht kann ich da einen oder mehrere erhöhen, die Frage ist welche(n).

Viele Grüße,
Thorsten

19
auf den Transponder schaltet

Hi Alex,

danke für den Gedanken. Ein Timer ohne VPS schaltet ja ebenfalls auf den Transponder, nur das reicht leider nicht sofern alle Tuner des Digibit gerade im Standby sind. Im Prinzip müsste er einmal auf einen anderen Transponder schalten und danach wieder zurück auf den, von dem aufgenommen werden soll.

Im Prinzip muss "nur" vor einer Aufnahme mal kurz auf irgendeinen Transponder geschaltet werden (nur nicht auf den, vom dem aufgenommen werden soll), damit der Unicable-Router aufwacht.
Ich werde noch kirre, da muss es doch einen simplen Weg geben  :-\

Danke und Grüße,
Thorsten

20
Ok, danke. Wird die diseqc.conf überhaupt benutzt (da ja alles über das satip-plugin läuft)?
Wenn das Umschalten lange dauert, wäre es nicht schlimm, da ich das nur auf dem Server machen würde damit die Timer-Aufzeichnungen funktionieren.

Gibt es eigentlich ein Skript, das aufgerufen wird sobald ein neuer Timer angelegt wird? Dann könnte ich evtl. automatisiert einen cronjob erstellen, der kurz vor der Aufnahme ein bisschen rumzappt...

Danke nochmals,
Thorsten


21
Cool, danke für den Tipp.
Hab es gerade ausprobiert, es wird zwar umgeschaltet, aber wieder zu spät.
Was dann passiert ist folgendes: Der Timer schaltet zuerst auf den Sender, der aufgenommen werden soll (bevor es das Skript schafft...).
Damit ist Frontend1 des Digibit belegt, liefert aber keine Daten wegen der bereits beschriebenen Problematik. Dann wird durch das "before"-Recording Skript auf z.B: ARD geschaltet. Damit wird Frontend2 auf dem Digibit belegt. Hier kommen nun Daten an, aber Frontend1 liefert nach wie vor keine Daten.

Das einzige was mir jetzt noch einfällt wäre im Skript die Aufnahme abzubrechen, einen Kanal anfordern, und dann wieder die Aufnahme zu starten. Irgendwie doof :-(

22
Hi,

danke für die Tipps. Bei der Variante als Hintergrundprozess (-d) wird zwar umgeschaltet, aber leider zu spät - der Timer schaltet vorher bereits um. Vermutlich ist in der Tat die svdrp-Schnittstelle blockiert und dann kommt der Umschaltbefehl zwar, aber erst nachdem alles vorbei ist.
Wie kann ich denn am einfachsten die restful-API verwenden? Hatte an wget gedacht, z.B.:

Code: [Select]
wget --method=POST http://IP:8009/remote/switch/S19.2E-1-1019-10301
allerdings kennt die wget Version von MLD den Parameter "--method" nicht. Oder kann ich das plugin direkt ansprechen?

Danke und Grüße,
Thorsten

23
Hallo zusammen,

bevor ich zu meinem Problem komme, hier kurz mein Setup: Ich verwende einen SAT>IP Server (Telestar Digibit R1) mit der satip-axe Firmware. Der Digibit bekommt sein Antennensignal von einem TechniRouter 5/1x4 (Unicable Router). Auf der VDR-Seite verwende ich dann einen Banana-Pi als VDR-Server und zwei RPi2 als VDR-Clients.

Das ganze läuft dank der o.g. satip-axe Firmware super - bis auf folgendes Problem:

Wenn alle Tuner vom Digibit im standby sind, hat natürlich der TechniRouter keine Versorgungsspannung mehr. Wenn jetzt von irgendeinem VDR eine Kanalanforderung kommt, werden die Unicable-Kommandos vom Digibit losgeschickt, allerdings scheint das so schnell zu gehen, dass der TechniRouter nocht nicht voll da ist, da er ja im Zuge des "Aufwachens" des Tuners ja erst seine Versorgungsspannung bekommt. Ich habe das auch mal als Issue auf Github eingestellt.

Zum TV schauen ist das natürlich kein Problem, dann schaltet man einfach am Anfang kurz einen Kanal weiter und dann läuft alles wie gewünscht.
Problematisch wird es bei einer Timer-Aufnahme: Der Timer fordert einen Kanal an, der Digibit fordert diesen beim Technirouter an aber der ist noch nicht voll da und bekommt es nicht mit. Ergebnis: eine Aufnahme mit 0 Byte... Mein aktueller Workaround: Ich programmiere zu jeder Aufnahme eine kurze Aufnahme (1 Minute) auf einem anderen Transponder, damit der TechniRouter aufwacht. Das ist natürlich ziemlich nervig.

Meine Idee war, ein "before"-Recording Skript zu nutzen, welches einen Kanal anfordert. Folgendes Skript habe ich getestet (liegt im Ordner /etc/vdr/recording.d/

Code: [Select]
#!/bin/sh
case "$1" in
     before)
            svdrpsend.sh 'CHAN 2' >/dev/null
            ;;
esac

Leider führt das nach 60s zu einem Neustart des VDR (watchdog...). Kanal 2 wird auch nie angefordert, dass sehe ich auf dem Digibit. Wenn ich das Skript manuell auf der Konsole starte, funktioniert es.
Hat jemand eine Idee?

Danke und viele Grüße,
Thorsten

24
Banana PI / DVBSky S960
« on: November 07, 2016, 16:19:47 »
Ok schade.

 :(

25
Banana PI / DVBSky S960
« on: November 06, 2016, 21:03:25 »
Hallo Claus,

mit dvb-liplianin kommt außer

Code: [Select]
usb 4-1: new high-speed USB device number 3 using sw-ehci
nichts.

Das gleiche mit dem dvb-Paket. Da scheint mir dvb-me noch am aussichtsreichsten.

Habe noch in diesem Thread etwas gefunden:

Ich bin grad nicht ganz sicher, aber der BPI verwendet noch einen recht alten Kernel, und für den lässt sich das dvb-sky wohl nicht bauen. Sobald wir da auf nen neueren Kernel wechseln können, wird's wohl auch dvb-sky geben. Das wird aber noch ein Bischen dauern.

Claus

Ist das nach wie vor das Problem?

Danke und Grüße,
Thorsten

26
Banana PI / DVBSky S960
« on: November 01, 2016, 22:39:02 »
Hallo zusammen,

Hier http://www.minidvblinux.de/forum/index.php/topic,7956.msg60895.html hatte ich gerade gelesen, dass die DVBSky auf dem RPi mit dem dvb-mbe Paket läuft.
Leider hatte ich mit einem BPi keinen Erfolg. Hier die Ausgabe von dmesg:

Code: [Select]
[  211.867011] usb 4-1: new high-speed USB device number 3 using sw-ehci
[  212.217363] usb 4-1: dvb_usb_v2: found a 'DVBSky S960/S860' in warm state
[  212.226136] usb 4-1: dvb_usb_v2: will pass the complete MPEG2 transport stream to the software demuxer
[  212.230778] DVB: registering new adapter (DVBSky S960/S860)
[  212.237048] usb 4-1: dvb_usb_v2: MAC address: 00:17:42:54:96:0c
[  212.255538] m88ds3103: Unknown symbol i2c_del_mux_adapter (err 0)
[  212.260768] m88ds3103: Unknown symbol i2c_add_mux_adapter (err 0)
[  212.265971] DVB: Unable to find symbol m88ds3103_attach()
[  212.269315] usb 4-1: dvbsky_s960_attach fail.

Gibt es für den BPi auch eine Lösung?

Danke und viele Grüße,
Thorsten

27
@MegaX: wie würdest Du die Ergebnisse interpretieren?

Danke und Grüße,
Thorsten

28
Hi,

hier das Ergebnis. Allerdings musste ich conv=fdatasync,notrunc weglassen, da die dd-Version der busybox das wohl nicht kennt.

CPU:   0% usr  25% sys   0% nic  30% idle  41% io   0% irq   1% sirq
Load average: 0.30 0.32 0.18 2/122 1937
  PID  PPID USER     STAT   VSZ %VSZ CPU %CPU COMMAND
 1937  1811 root     D     5144   1%   0  21% dd


und so sieht es mit count=4096 kurz vor "Fertigstellung" aus:

Mem: 764852K used, 20468K free, 540K shrd, 1192K buff, 637136K cached
CPU:   1% usr  30% sys   0% nic  20% idle  46% io   0% irq   1% sirq
Load average: 1.75 0.69 0.34 3/120 1946
  PID  PPID USER     STAT   VSZ %VSZ CPU %CPU COMMAND
 1945  1811 root     R     5144   1%   1  21% dd


Viele Grüße,
Thorsten

29
Hallo,

bei dem Test hatte ich in der Tat auf die SD-Card gespeichert.
Hier nochmal der gleiche Test mit einer SATA-Platte. Auch hier wird es ab der dritten Aufnahmen eng. Die Netzwerkverbindung ist nicht das Problem (Managed GbE-Switch). Testweise hab ich aber trotzdem mal meinen "normalen" PC an die gleiche Netzwerkdose mit dem gleichen Kabel angeschlossen. Der kann locker vier Streams...

1 Stream (Das Erste HD)
CPU:   9% usr  13% sys   0% nic  73% idle   1% io   0% irq   0% sirq
Load average: 0.44 0.65 0.34 3/122 7373
  PID  PPID USER     STAT   VSZ %VSZ CPU %CPU COMMAND
 1286   795 root     S     534m  70%   1  25% /usr/bin/vdr

2 Streams (Das Erste HD + ZDF HD)
CPU:  19% usr  27% sys   1% nic  45% idle   1% io   0% irq   4% sirq
Load average: 1.12 0.79 0.42 3/124 7386
  PID  PPID USER     STAT   VSZ %VSZ CPU %CPU COMMAND
 1286   795 root     S     570m  74%   0  53% /usr/bin/vdr

3 Streams (Das Erste HD + ZDF HD + Arte HD)
CPU:  25% usr  39% sys   1% nic  26% idle   2% io   0% irq   5% sirq
Load average: 1.92 1.07 0.55 5/125 7399
  PID  PPID USER     STAT   VSZ %VSZ CPU %CPU COMMAND
 1286   795 root     S     598m  78%   1  71% /usr/bin/vdr

4 Streams (Das Erste HD + ZDF HD + Arte HD + ZDF neo HD)
CPU:  31% usr  46% sys   2% nic   6% idle   1% io   0% irq  10% sirq
Load average: 2.66 1.51 0.76 5/126 7411
  PID  PPID USER     STAT   VSZ %VSZ CPU %CPU COMMAND
 1286   795 root     S     627m  82%   0  91% /usr/bin/vdr


Danke und viele Grüße,
Thorsten

30
Also hier das Ergebnis des Testlaufs.
Auch wenn es von den Werten her bei drei Aufnahmen noch gut ausschaut - die Aufnahme ist unbrauchbar.
Mich wundert die hohe CPU-Last von VDR selbst, da gibt es ja eigentlich nichts zu tun. Daten empfangen und 1:1 wegschreiben...
So richtig verstehe ich immer noch nicht, was der Flaschenhals ist.

1 Stream (Das Erste HD)
   CPU:   9% usr  18% sys   0% nic  64% idle   5% io   0% irq   1% sirq
   Load average: 0.66 2.23 1.60 2/122 2434
     PID  PPID USER     STAT   VSZ %VSZ CPU %CPU COMMAND
    1285   803 root     S     550m  72%   0  27% /usr/bin/vdr

2 Streams (Das Erste HD + ZDF HD)
   CPU:  18% usr  39% sys   1% nic  27% idle   8% io   0% irq   5% sirq
   Load average: 2.16 2.24 1.67 7/124 2447
     PID  PPID USER     STAT   VSZ %VSZ CPU %CPU COMMAND
    1285   803 root     S     570m  74%   0  59% /usr/bin/vdr

3 Streams (Das Erste HD + ZDF HD + Arte HD)
   CPU:  20% usr  58% sys   1% nic   7% idle   4% io   0% irq   7% sirq
   Load average: 3.67 2.65 1.87 3/126 2461
     PID  PPID USER     STAT   VSZ %VSZ CPU %CPU COMMAND
    1285   803 root     S     590m  77%   0  81% /usr/bin/vdr

4 Strams (Das Erste HD + ZDF HD + Arte HD + ZDF neo HD)
   CPU:  27% usr  61% sys   1% nic  0% idle   0% io   0% irq   9% sirq
   Load average: 7.31 4.19 2.51 9/127 2473
     PID  PPID USER     STAT   VSZ %VSZ CPU %CPU COMMAND
    1285   803 root     S     618m  81%   0  91% /usr/bin/vdr


Viele Grüße,
Thorsten