[Support] alturismo - Repos

[alturismo]

3 hours ago, Rick Gillyon said:

Hi @alturismo, when I launch a shell in this docker, the /usr/cvlc is 2.5 years old. I'm not sure if that's coming from this docker or if it's from elsewhere, can you advise how to update if it's not here? Thanks for the great docker btw.

its the vlc package coming from apk add vlc

 

and im not experimenting now with others, does its job when used ...

 

may a side question, why would you need a newer vlc ?

as note, its the last option you should choose in terms of issues for remuxing ...

[Rick Gillyon]

4 hours ago, alturismo said:

may a side question, why would you need a newer vlc ?

as note, its the last option you should choose in terms of issues for remuxing ...

vlc seems to be working fine but throws a lot of errors, e.g.

2020-12-09 02:32:54 [xTeVe] Streaming Status:      Receive data from VLC
2020-12-09 02:32:54 [xTeVe] VLC log:               [0000563efd486500] main interface error: no suitable interface module
2020-12-09 02:32:54 [xTeVe] VLC log:               [0000563efd487c20] main interface error: no suitable interface module
2020-12-09 02:32:54 [xTeVe] VLC log:               [0000563efd487c20] dummy interface: using the dummy interface module...
2020-12-09 02:32:55 [xTeVe] Streaming Status:      Buffering data from VLC

And why use? My ipTV service has recently changed something, and as a result it errors out when using the xTeVe buffer with Emby:

2020-12-09 00:00:10 [xTeVe] Buffer: true [xteve]
2020-12-09 00:00:10 [xTeVe] Buffer Size: 1024 KB
2020-12-09 00:00:10 [xTeVe] Channel Name: 5USAB
2020-12-09 00:00:10 [xTeVe] Client User-Agent:
2020-12-09 00:00:10 [xTeVe] Streaming Status: Playlist: ipTV - Tuner: 1 / 3
2020-12-09 00:00:10 [xTeVe] Streaming Type: [TS]
2020-12-09 00:00:10 [xTeVe] Streaming URL: http://url.url.net:80/USER/PASS/4766
2020-12-09 00:00:11 [xTeVe] Streaming Status: HTTP Response Status [200] OK
2020-12-09 00:00:11 [xTeVe] Content Type:
2020-12-09 00:00:11 [xTeVe] Content Type:
2020-12-09 00:00:11 [xTeVe] [ERROR] Streaming error (Server sends an incompatible content-type) - EC: 4003

vlc is the only thing that works for it. They say they only changed dns, but it's broken the service for Emby (all my other clients work fine, Emby is the only one using xteve).

Edited December 9, 2020 by Rick Gillyon

[alturismo]

@Rick Gillyon if its only the logging u can disable it by adding -q

 

-I dummy --sout #std{mux=ts,access=file,dst=-} -q

 

the error is only due there is no display connected to the docker  and i force cvlc to work anyway

 

and my best bet is rather your provider wants to block other clients, so may take a look at the xteve user agent settings

 

sample line for xteve buffer (there is always a description)

VLC/3.0.8 LibVLC/3.0.8

 

Edited December 9, 2020 by alturismo

[Rick Gillyon]

Thanks for that. It worked with the xteve buffer with that vlc user agent, so I changed back to the xTeVe user agent and it's still working. Looks like they fixed it overnight.  Thanks anyway!

[alturismo]

small update on the xteve dockers (besides _vpn edition), in terms xteve is used behind a Reverse proxy and cached images are activated, the urls to the icons, picons where not rewritten.

 

i made a small workaround therefore, a extra xml is generated with rewritten urls which can be used as

https://mydomain.de/xmltv/xteverp.xml in the client apps.

 

to make use of it, backup your cronjob.sh (to save your settings), remove it, restart docker (to get a new updated one), make your settings, restart docker.

 

when you dont need this feature you can ignore it.

[RollingK]

Thank you for all the effort you've put into this docker. The VPN connection is working and I can watch streams in VLC using the .m3u url using ffmpeg transcode.

 

Is it possible to make the ffmpeg binary available to a Tvheadend Docker? Tvheadend doesn't seem to work when ffmpeg transcoding is enabled within xteve. I found a solution on the Tvheadend forums that involves accessing the ffmpeg binary from tvheadend.

 

xteve vpn to tvheadend using ffmpeg

[alturismo]

5 hours ago, RollingK said:

vheadend doesn't seem to work when ffmpeg transcoding is enabled within xteve

 

Hi, xteve by default aint transcoding, just remuxing to a .ts stream (as long you didnt modify the ffmpeg line)

 

TVH and iptv input (m3u from xteve is more or less the same, just local), you need to pipe through ffmpeg inside TVHeadend, depending now on your docker ffmpeg is included there (sample linuxserver), so you should be fine already when you use pipe ...

 

search for pipe input iptv in tvheadend and you get a clue what todo, some manual adjustements in the input lines.

 

may i ask the usecase you like to achive ? just out of interest  i also use tvheadend but vice vers, input to tvheadend, from tvheadend to xteve ...

[RollingK]

21 hours ago, alturismo said:

may i ask the usecase you like to achive ? just out of interest  i also use tvheadend but vice vers, input to tvheadend, from tvheadend to xteve ...

Thank you for your reply! Saved me a lot of guesswork regarding ffmpeg.

 

My goal is to stream from an IPTV provider -> xteve with VPN -> Tvheadend -> Kodi with Tvheadend Addon.

 

I got it working now by editing the m3u provided by xteve and embedding the URL it provides into:

pipe://<PATH TO FFMPEG> -i <IPTV URL> -c copy -f mpegts pipe:1

 

I'm running the Linuxserver Tvheadend so it looks like this:

pipe:///usr/bin/ffmpeg -i <IPTV URL> -c copy -f mpegts pipe:1

 

 

[ryanleeis]

could someone please help me out .  I’ve read the instructions on how to get two instances of this running with two different ports but I just can’t seem to get it to use the second port can someone please help me out here

[alturismo]

2 hours ago, ryanleeis said:

 I’ve read the instructions on how to get two instances of this running with two different ports

may describe what you done so someone may could help

[thedman]

Any chance of making an xteve_vpn docker with zap2it support as well?

 

[alturismo]

19 hours ago, thedman said:

Any chance of making an xteve_vpn docker with zap2it support as well?

 

i dont use zap myself, but may a question ahead, does it work using a VPN and outside US/CA ?

[relink]

My guide ends up blank almost every morning. I’ve been running your Xteve guide2go container for a couple years now. A few weeks ago I started loosing guide data almost every morning. 
 

I changed IPTV providers last week so I took the opportunity to start over from scratch, new cron.sh, new yaml files, everything should be new. I thought I fixed it, but I woke up today to no guide data again. 
 

not sure what else to check?

[alturismo]

8 minutes ago, relink said:

not sure what else to check?

 

also not sure from here what to say

 

1st start would be, running cron manually, does it run through and work ?

 

if yes, what schedulees do you use (default, changed time by editing cron.txt) ...

does your xmltv source provides data for more then your cron schedules ? sample, more then 1 day ... if so, run the schedule more often ...

 

if you have way more and alot of channels as sample, i saw where it crashes due out of memory, may split your yaml in more single setups ...

 

that would be my start

[relink]

10 hours ago, alturismo said:

1st start would be, running cron manually, does it run through and work ?

Yup, I ran it manually and everything worked fine.

 

10 hours ago, alturismo said:

if yes, what schedulees do you use (default, changed time by editing cron.txt) ...

does your xmltv source provides data for more then your cron schedules ? sample, more then 1 day ... if so, run the schedule more often ...

Im not sure I follow, I have 3 lineups all very small, 79 channels , 19 channels and 9 channels. and each one has its own yaml. All 3 are set to download 14 days of guide data, and the cron is whatever the default in the container is.

 

Part of the issue seems to be that already downloaded data is being replaced by nothing. I ran cron manually today, and currently have data but there is a good chance I will wake up tomorrow and have no guide data again.

[alturismo]

6 hours ago, relink said:

3 lineups all very small, 79 channels , 19 channels and 9 channels.

ok, the 79 channels lineup with 14 days, does work nice here but i have alot of RAM, just as test, may split this one in 2 seperate ones (copy the yaml, remove the half from 1 lineup, the other half from the other lineup), EPG generating takes alot of ressources (RAM).

 

or, by default its triggered at 0.00 am, may change your fetch time (read cron.txt), SD is also on some times "overloaded".

 

this would be my next 2 steps to check.

[relink]

On 11/12/2021 at 11:47 PM, alturismo said:

the 79 channels lineup with 14 days, does work nice here but i have alot of RAM

I can certainly try it if nothing else works, but I've had bigger lineups than that working for almost a year, on the same system with 32GB ram.

 

On 11/12/2021 at 11:47 PM, alturismo said:

or, by default its triggered at 0.00 am, may change your fetch time (read cron.txt), SD is also on some times "overloaded".

I think ill check into this first, as the g2g cron, xteve, and Plex all update at the exact same time. Im going to try and stagger them.

 

However I am going on 2 days and I still have guide data so far....

[Rick Gillyon]

Plex will (or at least used to) happily import an empty file and lose all your data. So I have g2g run first to an interim file (e.g. lineup1_temp.xml), then my script checks the size. If the size is good, I copy lineup1_temp.xml to lineup1.xml, which xteve will import. If not good I leave yesterday's lineup1.xml in place for xteve. SD is pretty flakey these days for me, probably fails once a week.

Edited November 15, 2021 by Rick Gillyon

[relink]

7 hours ago, Rick Gillyon said:

Plex will (or at least used to) happily import an empty file and lose all your data.

Im thinking this was the issue, g2g, xteve, and Plex were all updating around midnight, so if g2g or xteve wasn't done yet and plex did its import that would explain why my guide would have been empty.

 

So what I did was changed the cron.txt so that g2g updates at 9:00pm, I set xteve to update at 10:00pm, and left Plex at its default of between 11:00pm-Midnight. This way there is absolutely zero chance any one of them will ever overlap.

[epp]

I have a m3u8 that xTeVe doesn't seem to support:

https://rbmn-live.akamaized.net/hls/live/2002830/geoSTVDEweb/master.m3u8

 

Here's the contents:

 

#EXTM3U
#EXT-X-VERSION:3
#EXT-X-INDEPENDENT-SEGMENTS
#EXT-X-STREAM-INF:BANDWIDTH=677600,AVERAGE-BANDWIDTH=655600,CODECS="avc1.77.30,mp4a.40.2",RESOLUTION=640x360,FRAME-RATE=25.000
https://rbmn-live.akamaized.net/hls/live/2002830/geoSTVDEweb/master_596.m3u8
#EXT-X-STREAM-INF:BANDWIDTH=1856800,AVERAGE-BANDWIDTH=1790800,CODECS="avc1.4d401f,mp4a.40.2",RESOLUTION=960x540,FRAME-RATE=25.000
https://rbmn-live.akamaized.net/hls/live/2002830/geoSTVDEweb/master_1628.m3u8
#EXT-X-STREAM-INF:BANDWIDTH=3872000,AVERAGE-BANDWIDTH=3731200,CODECS="avc1.4d401f,mp4a.40.2",RESOLUTION=1280x720,FRAME-RATE=25.000
https://rbmn-live.akamaized.net/hls/live/2002830/geoSTVDEweb/master_3392.m3u8
#EXT-X-STREAM-INF:BANDWIDTH=7647200,AVERAGE-BANDWIDTH=7361200,CODECS="avc1.4d4028,mp4a.40.2",RESOLUTION=1920x1080,FRAME-RATE=25.000
https://rbmn-live.akamaized.net/hls/live/2002830/geoSTVDEweb/master_6692.m3u8

 

Can xTeVe handle #EXT-X-STREAM-INF?

 

Also if I try to add any of the m3u8's listed there it says: Invalid M3U file, an extended M3U file is required.

 

Is that just a limitation of what xTeVe can do or is there any way to get the file working?

 

 

[alturismo]

5 minutes ago, epp said:

I have a m3u8 that xTeVe doesn't seem to support:

 

 

as you see this is a real m3u8 with ABR and AR which is not to handle properly for the purpose of xteve without a complete reencoding to use in plex.

 

ABR (Adaptive Bitrate) and AR (Adaptive Resolution) are no formats which can be simply remuxed to a .ts stream, VLC would play them, yes, but a client like Plex as sample will simple stop the playback as soon a switch comes in.

 

so in short, nope, not supported

[epp]

5 minutes ago, alturismo said:

 

as you see this is a real m3u8 with ABR and AR which is not to handle properly for the purpose of xteve without a complete reencoding to use in plex.

 

ABR (Adaptive Bitrate) and AR (Adaptive Resolution) are no formats which can be simply remuxed to a .ts stream, VLC would play them, yes, but a client like Plex as sample will simple stop the playback as soon a switch comes in.

 

so in short, nope, not supported

 

Any way at all to convert that so it would work? I'm asking because there does not seem to exist an alternative stream for that channel, that's why I'm clinging on that straw

[alturismo]

 
Any way at all to convert that so it would work? I'm asking because there does not seem to exist an alternative stream for that channel, that's why I'm clinging on that straw

Remind me on sunday, i take a look

Gesendet von meinem SM-G981B mit Tapatalk

[epp]

On 12/3/2021 at 7:19 PM, alturismo said:

Remind me on sunday, i take a look

Gesendet von meinem SM-G981B mit Tapatalk
 

No hurry, would be great if it would be possible somehow though 😅

[alturismo]

1 hour ago, epp said:

No hurry, would be great if it would be possible somehow though 😅

 

now, if its only this one channel, quick & dirty but working

 

choose the quality you would like as input, as sample i stripped your file down now to 1080p only (highest quality)

 

#EXTM3U
#EXTINF:0,master.m3u8
#EXTVLCOPT:network-caching=1000
https://rbmn-live.akamaized.net/hls/live/2002830/geoSTVDEweb/master_6692.m3u8

 

like this i just drive around the ABR AR i explained above ...

 

now import this file into xteve

 

 

assign a epg in case you use xepg

 

update plex playlist

 

 

enjoy your channel in plex ...

 

 

2021-12-05 22:10:54 [xTeVe] Streaming Status:       Playlist: test - Tuner: 1 / 1
2021-12-05 22:10:54 [xTeVe] Streaming URL:          https://rbmn-live.akamaized.net/hls/live/2002830/geoSTVDEweb/master_6692.m3u8

 

you can also use a lower resolution, look at your 4 available streams ... in terms its too high, its using pretty high bitrate here ...

 

also you can check which buffer fits best in terms of reliability, xteve, ffmpeg or may even vlc, in this order i would test throuh.