Beiträge von andmy

Hallo, habe das Addon in der Version 16.5.12 installiert, vielen Dank dafür.
Leider funktionierte bei mir die merged_epg.xml.gz nicht, da der der Start-XML-Tag <tv> (von der zweiten Datei) dort zu einem Fehler führte. Der schließende Tag </tv> wird grundsätzlich gelöscht, ich schlage vor auch den Start-Tag (ab dem zweiten) zu löschen. Dafür habe ich die common.py geändert, patch anbei. Bei mir funktioniert es so, habe es aber auch nur mit meinem Beispiel getestet.

Zitat von narziss

So jetzt passts..

Danke für eure Unterstützung. Jetzt muss ich nur noch austüfteln wie ich dynamische Links einfügen bzw. immer wieder ersetzen kann.

Ich habe mir dafür ein kleines PHP Script geschrieben. Das einzige Problem damit ist, dass das Scannen der Muxes mehrfach ausgefüht werden muss, bis alle Services da sind.

//file location, can be remote over http(s)
const PLAYLIST_LOCATION = 'deutsch.m3u8';


const PREFIX = 'pipe:///usr/local/tvheadend-testing/bin/ffmpeg -loglevel fatal -i ';
const SUFFIX = ' -vcodec copy -acodec copy -metadata service_provider=IPTV -metadata service_name=_SERVICE_NAME_ -f mpegts -tune zerolatency pipe:1';


header("Content-type: text/plain");
header("Content-Disposition: attachment; filename=playlist2.m3u8");


$lines = file(PLAYLIST_LOCATION);


$serviceName = 'unknown';


foreach ($lines as $line_num => $line) {
	//extract servicename from #EXTINF line
	if (strcmp (strtoupper(substr($line,0,7)),'#EXTINF')==0) {
		$pos = strpos($line, ',', 0);
		$serviceName = utf8_encode(trim(substr($line,($pos+1),strlen($line))));
	}
	//extract href and append
	if (strcmp (strtoupper(substr($line,0,7)),'HTTP://')==0) {
		$suffid_mod = str_replace('_SERVICE_NAME_',$serviceName,SUFFIX);
		print PREFIX.trim($line).$suffid_mod.PHP_EOL;
		$serviceName = 'unknown';
    } else
    	//print other lines without change
    	print $line;
}

Zitat von narziss

Könntest du mir deinen String dann mal durchgeben ?
Wie gesagt ich verzweifel ein wenig. Ich weiss, dass es umsetzbar ist komme aber nich wirklich dahinter wie was und warum.

pipe:///usr/local/tvheadend-testing/bin/ffmpeg -loglevel fatal -i http://daserste_live-lh.akamaihd.net/i/daserste_de@91204/index_2692_av-b.m3u8?sd=10&rebase=on -vcodec copy -acodec copy -metadata service_provider=IPTV -metadata service_name=test -f mpegts -tune zerolatency pipe:1

Praktisch wie bei Dir auch, bloß habe ich systembedingt andere Pfade, ja, und geographisch bedingt anderen Link
Ich habe diesen im Mux als URL eingestellt.

Also ich denke, dass TVHeadend hier wirklich mit dem HLS Protokoll ein kleines Problem hat. Daher sollten konvertierte Streams im TS-Format besser funktionieren. AFAIK kommen die ja so vom SAT auch und funktionieren im TVH einwandfrei.

Zitat von CvH

das ist quasi das selbe wie die Pipe wenn ich mich recht erinnere

node-ffmpeg-mpegts-proxy nutzt scheinbar einen anderen Konverter, und zwar avconv statt ffmpeg (den bei mir tvheadend mitbringt).

Zitat von narziss

Ich werde es mal mit

https://github.com/Jalle19/node-ffmpeg-mpegts-proxy

probieren

Das hört sich ganz gut an, könnte funktionieren.
Ich habe gerade ein paar Streams mit pipe laufen lassen, es sieht nicht schlecht aus. Teste heute Abend mal ausgiebig.

Zitat von narziss

Na für mich eben schon ..

Für mich nur wenn es sehr zuverlässig funktioniert, sonst lacht mich meine Frau wieder aus

Ja, es ist ja schon gemeldet als Bug #3843, wobei der Entwickler im Kommentar auf ein Feature Request #3838 verweist und eben auch auf das Workaround mit der pipe.. Ich gehe fest davon aus, dass es demnächst behoben wird, da IPTV auf TVH so nicht wirklich einen Mehrwert hat.

Zitat von narziss

Ich bin des englischen zwar mächtig und habe auch die nötigen IT Kenntnisse, allerdings habe ich bisher kaum Erfahrungen mit dem tvheadend IPTV Zeugs .. Mit dem Pipen habe ich allerdings bereits versucht und komme zum gleichen Ergebnis.

Ja, deswegen sind wir ja hier Ich nutze bisher die Playlists direkt im Kodi (PVR IPTV Simple Client), was auch sehr stabil funktioniert und wollte wegen Time Shift- und Aufnahmefunktionen auf tvheadend umsteigen. Daher teste ich diesen seit 3 Tagen. Ich hatte mich für die unstabile 4.1 entschieden, da diese Version angeblich IPTV besser unterstützt, insbesondere einfügen mehrer Quellen (Muxes) über eine Playlist.
Dieses "Feature", das die Verbindung, auch während einer Aufnahme trennt, macht das Ganze für mich unbrauchbar Ich teste nun auch meinerseits mit der pipe...

Vielleicht ist es doch ein Feature #3843
Das was dort beschrieben ist, ist auch abhängig vom Stream. Es ist daher logisch, dass es mit einigen Streams häufig auftritt und mit anderen (fast) gar nicht.

Versucht mal Konfiguration->Stream->htsp (Expert) "Neustart nach Fehler" Häckchen setzen, wenn es das in 4.0.8 schon gibt.

Zitat von narziss

Die ist noch unstable .. Kannst du es mit meinem Link mal probieren ?

Ja stimmt, wollte aber die Feautres haben. Leider sind alle Links Access denied

Bei mir läuft diese daserste im tvheadend. Habe TVHeadend Version 4.1.2116

Soweit ich sehen kann unterstützt das TVHeadend HTSP Client nur einen Server. Ich würde das so machen, dass ich die Kanäle des ersten Servers als Playlist im zweiten einbinde und den zweiten im Client konfiguriere, oder spricht da was gegen?

Zitat von CvH

Bei Kodi 16.1 ist 2.2.10 bzw 2.2.20 aktuell , 1.9.40 ist der Client der bei Kodi 15 dabei ist. Kodi 16.x hat mindestens den 2.x - evtl Repo weg bzw falsch (je nach System)?

Wie jetzt IPTV Simple Client oder Tvh - über was spielst du nun ab ? Weil beide Addons gleichzeitig aktiviert wirst du ja nichth aben (weil es nicht geht).

Ok, das muss ich mal prüfen, danke.

Ich verstehe das jetzt auch nicht ganz. Was mir aufgefallen ist, dass bei IPTV Simple Client Testvideos nicht dieselben Kanäle getestet wurden. Es ist möglich, dass innerhalb der Playlist bei verschiedenen Kanälen auch unterschiedliche Server genutzt werden und es deshalb unterschiedlich lang dauert. Ich nutze IPTV Simple Client und Teste TVHEadend HTSP Client gerade unter Kodi 16.1 (IPTV Simple Client habe ich bereits unter Kodi 14 und 15 genutzt ) und hatte noch nie Probleme mit Umschaltzeiten. Nutze jedoch immer denselben IPTV Provider. Als Betriebssysteme für Kodi nutze ich allerdings FireTV, Android und Windows (zum testen).

Zitat von CvH

welches System ? Das sollte die Version von Kodi 15.0 sein wenn ich das recht in Erinnerung habe

Es ging um die Version des TVHeadend HTSP Clients, den bringt bei mir Kodi mit. Kodi ist in der 16.1. stabil.

Zitat von Kampfi

auf einem Kodi system aka. Openelec, Libreelec oder Ubuntu system aka. Raspbian?

Ich habe eine etwas andere Konfiguration. TVHeadend lasse ich auf Synology - NAS laufen, dort habe ich auch den Grabber (tv_grab_ru) installiert und zwar in /usr/local/tvheadend/bin und ausführbar gemacht. Nach TVHeadend neustart war der Grabber sofort da und musste nur aktiviert werden (Konfiguration->Kanäle/EPG->EPG-Grabber Module).
Ich nutze bis jetzt nur eine Playliste, ich denke aber, dass im TVHeadend mehrere problemlos möglich sind, vermutlich muss man weitere Netzwerke hinzufügen.

So nun stimmt auch die EPG Zeit. In TVHeadend habe ich unter Konfiguration->DVB-Input->Netzwerke (Expertenansicht) EIT-Zeitversatz auf UTC+4 gestellt (für Russisches EPG)

Zitat von CvH

da solltest du dringendst auf irgendwas aktuelles Updaten - evtl ist der Fehler dann auch schon weg

Ich ging ehrlich gesagt davon aus, dass ich die Neueste (stabile) habe, da keine Updates gefunden werden. ICh denk, dass es nicht wirklich ein Fehler ist, da es russisches EPG ist (UTC+4), man müsste halt im TvHeadend die Zeitverschiebung einstellen können.

Hallo,

habe gerade etwas zum Thema gegoogelt und Dein Post gefunden. Ich hoffe Du hast noch nicht aufgegeben Ich bin schon einen Schritt weiter, bei mir läuft das EPG, nur den Zeitversatz bekomme ich nicht rein

Bei mir ist TVHEadend client in der Version 1.9.40 installiert.

Ja genau, im Kodi erscheinen die Kanäle dann im EPG, das funktioniert schon. Ich habe ein bash-Script (hier) gefunden und den als Grabber installiert. Funktioniert bei mir bis auf Zeitverschiebung einwandfrei.