Beiträge von kammann

Tolles Skript! Funktioniert mit den meisten ÖR Programmen einwandfrei. Leider habe ich bei allen privaten Sendern (RTL, Pro7) jeweils alle 4 Sekunden im Wechsel mit dem normalen Fernsehbild eine Hinweistafel "We seem to have a problem here - The source signal is interrupted, we are working on a fix". Der Ton läuft dabei ohne Unterbrechung weiter - getestet mit Version 4.0.6 unter Ubuntu 20.04 sowohl unter VLC als auch tvheadend (mit ffmpeg). Plattform ist auch egal (hls, hls5, hls7), ebenso der Account (Zattoo Free oder 1&1, also auch unterschiedliche Server). Im Logfile von telerising gibt es keine Einträge, allerdings weiss ich hier nicht, wie ich den Loglevel erhöhen kann (umstellen von "fatal" auf "[definition=12,0]debug[/definition]" scheint keine Auswirkung zu zeigen. Tvheadend loggt "continuity errors".

Hat jemand eine Idee wo das Problem liegt? Die Hinweistafel scheint ja von Zattoo zu kommen, das finde ich sehr merkwürdig...

Leider verarbeitet auch weder VLC noch tvheadend die von telerising erstellte Channel-List, d.h. ich muss die Angaben aus der M3U-Datei manuell in VLC als Netzwerkstream öffnen.
also
http://192.168.1.111:8080/?file=channels.m3u&bw=8000&platform=hls
kann VLC nicht verarbeiten, die Angabe eines bestimmten Senders (hier: CNN)
http://192.168.1.79:8080/index.m3u8?channel=cnn-international&platform=hls
hingegen schon.

Dito tvheadend. Ich muss für jeden Sender einen Mux hinzufügen weil die Angabe zum m3u-File (erzeugt mit

http://192.168.1.111:8080/?file=channels.m3u&bw=5000&platform=hls5&ffmpeg=true

nur zu einem "FAIL" beim Scannen des MUX in tvheadend führt). Öffne ich das m3u file mit einem Editor und richte einen einzelnen Stream von Hand (pipe-Kommando) als neuen MUX ein, so funktioniert es (für diesen einzelnen Stream).

Hi,
nach Neuinstallation meines Univention-Servers mit eigener VM für tvheadend dachte ich, ich könnte "mal schnell" auch 1&1 TV über das Telerising-Skript zum Laufen zu bringen. Die Grundinstallation des Skripts läuft, ich kann mit VLC testweise das M3U-File (im hls-Mode) öffnen und relativ fix durch 82 Kanäle zappen.

Wenn ich den umfangreichen Thread hier richtig interpretiere, dann sollte für tvheadend das M3U-File für die hls5-Plattform und ohne ffmpeg funktionieren:

http://192.168.1.111:8080/?file=channels.m3u&bw=5000&platform=hls5

Ein neuer Adapter "IPTV automatic network" mit diesem M3U-File durchsucht zwar die 82 Kanäle, jeder Scan schlägt aber fehl mit:
2020-09-06 18:53:20.646 [ INFO] mpegts: - ZDF HD in Test - tuning on IPTV #2
2020-09-06 18:53:20.647 [ INFO] epggrab: - ZDF HD in Test - registering mux for OTA EPG
2020-09-06 18:53:20.647 [ INFO] subscription: 0039: "scan" subscribing to mux " - ZDF HD", weight: 5, adapter: "IPTV #2", network: "Test", service: "Raw PID Subscription"
2020-09-06 18:53:35.646 [ INFO] mpegts: - ZDF HD in Test - scan no data, failed

Offenbar bekommt mpegts keine Daten vom Telerising-Skript. Die Ausgaben des Skripts sehen normal aus, insb. kommen die Anfragen von tvheadend an:
* 2020-09-06 19:38:49 LIVE-TV zdf | 5000 | hls5 - Loading Live URL
* 2020-09-06 19:38:49 LIVE-TV zdf | 5000 | hls5 - Loading channel configuration
* 2020-09-06 19:38:49 LIVE-TV zdf | 5000 | hls5 - Loading M3U8

Verwende ich hingegen eine M3U-Liste mit aktiviertem ffmpeg, dann funktioniert es zwar, die Umschaltzeiten sind aber im Vergleich zum Zugriff per VLC sehr lang (etwa 3-4 Sekunden, dann nochmal 1-2 Sekunden Standbild mit Ton).
Kann das Telerising-Skript überhaupt einen für mpegts notwendigen TS-Stream liefern?

Hallo,

weiss jemand, warum Live TV deutlich mehr CPU Last verursacht als das Abspielen von Aufnahmen?
Auf meinem Sony TV (X8505) funktioniert Kodi+ pvr-tvheadend einwandfrei beim Abspielen von TV-Aufnahmen, egal ob MPEG2/4 oder HECV codiert, die CPU Last bleibt bei 50-60%.
Beim Live-TV steigt die CPU Last auf 100%, Ton ist einwandfrei, aber es fehlen Video frames.

Auf Github kommentiert ksooo in einem anderen Issue (https://github.com/kodi-pvr/pvr.hts/issues/286):
>I think pvr.hts uses demuxer for live tv only. We are talking about playback of recordings here which is implemented using vfs api.

Somit vermute ich, dass die hohe CPU-Last im Live TV durch den Demuxer verusacht wird. Merkwürdigerweise beobachte ich diesen Unterschied nicht auf anderen Android-Geräten, z.B. läuft auf einem älteren Sony-Tablet sowohl Live-TV als auch die Aufnahmen einwandfrei.

Hat jemand eine Idee, woran das liegt?

Zitat von cberinger

Hatte mir gedacht, dass er schon bei einem " incoming call" eine Player action auslöst.

Kann man irgendwo einstellen, dass die Aktion bereits bei Signalisierung eines Anrufs ausgelöst wird?
Gerade bei älteren Anwendern, die evtl. das Telefon nicht hören (und die kleine Einblendung übersehen...) wäre es sehr praktisch wenn man den Ton bereits stumm schaltet während das Telefon klingelt.