Closed crackers8199 closed 3 years ago
not always, BTW. right now i have american gladiators on and it has been fine...but earlier when i tried to watch deal or no deal, it changed after about 30 seconds.
Odd
extremely. i'll keep an eye on the logs and see if anything looks strange next time i see it happen.
I have Pluto running and connected to Emby (until Channels DVR can work) and I noticed that while Emby is recording one channel and I'm watching a different channel, the channel I'm watching live will switch to the channel that is recording. I exit to the guide and restart the live channel and it works correctly most of the time.
I have not noticed this with Locast.
Both use the same underlying core, so this would be PlutoTV specific for sure.
The channels, epg, and stream information are gathered straight from their API
Both use the same underlying core, so this would be PlutoTV specific for sure. Did some tests with Locast. Recorded a channel and watched another Locast channel with no switching occurring.
Thought I'd post another symptom in case it helps with debug. Sometime I will get video from one channel mixed with audio from another channel.
I'll get to this issue within the week, but I'm fairly certain that the issue is on PlutoTVs end.
I can push a change that may or may not help.
Awesome. I'll test when the update is ready.
you can try as of fHDHR/fHDHR_PlutoTV#33 which removes the caching of stream url caching
will do.
Upgraded to the latest version and the channel switching is still happening. Also got the switched audio as well. Once this happens, re-selecting the channel fixes the problem.
Integration with Channels-DVR is working! Both Pluto and Locast fHDHR. Sweet.
Upgraded to the latest version and the channel switching is still happening. Also got the switched audio as well. Once this happens, re-selecting the channel fixes the problem.
Integration with Channels-DVR is working! Both Pluto and Locast fHDHR. Sweet.
make sure you turn on force_best, especially if you're using ffmpeg. there's an issue where ffmpeg can't handle variant playlists and will cause the feed to skip occasionally without force_best enabled.
Just sent this note to the ChannelsDVR developers Reading some more in the whirlpool thread, this problem has been reported on just about every platform. Seems related to support (or lack thereof) for the #EXT-X-DISCONTINUITY tag. They have provided fixes for Kodi in their Inputstream.Adaptive addon.
I additionally found this patch for ffmpeg (not sure why it's not been accepted) http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20180316/739542e4/attachment.obj
Just an FYI....
Well...I wouldn't have believed it. I switched to the Channels docker for generating the m3u/xml files and with only that change I've been streaming 3 Pluto channels simultaneously for over an hour without any switch or stream hang where before I couldn't go more than about 5 minutes (using the native Channels M3U support). I do occasionally see a glitch in the stream that before I think would have caused a hang.
I'd recommend looking at the URL generated to pull the stream and see what's different (one that jumps out is the lack of a serverSideAds=true tag per the Channels developer)
I am using on fHDHR_PlutoTV on windows using the new Threading option and I'm getting a segment that just keeps looping on Plex. I've tried on multiple channels and the same thing happens. If I exit and come back in a new segment will start looping. I have also had the issue in this thread where another channel starts playing.
I haven't had the chance to dig at this, but I swear it's gotta be on Plutos end
Just a quick follow up. Since I changed from fHDHR to the new M3U support in ChannelsDVR (with their Pluto M3U/EPG generator) things have run flawlessly. No channels changes or hangs or mixed audio.
Just a quick follow up. Since I changed from fHDHR to the new M3U support in ChannelsDVR (with their Pluto M3U/EPG generator) things have run flawlessly. No channels changes or hangs or mixed audio.
same thing here. this has to be something with the way fHDHR is pulling the streams.
fHDHR literally just get the m3u8 from their API
going to quickly glance at @john9527 's suggestion to look at "serverSideAds=true"
To preface, I hadn't experienced any of the above symptoms in my testing with either plex or emby,,,
So the parameters that were adapted from their API look like this:
{'advertisingId': '', 'appName': '', 'appVersion': 'unknown', 'architecture': '', 'buildVersion': '', 'clientTime': '', 'deviceDNT': '0', 'deviceId': 'unknown', 'deviceLat': '[REDACTED]', 'deviceLon': '[REDACTED]', 'deviceMake': 'Chrome', 'deviceModel': 'Chrome', 'deviceType': 'web', 'deviceVersion': 'unknown', 'includeExtendedEvents': 'false', 'marketingRegion': 'US', 'sid': '[REDACTED]', 'userId': '[REDACTED]'}
Setting paramdict["serverSideAds"] = "true"
in the code doesn't seem to have any negative effect on streams from my perspective.
Can one of you test the new push?
nvm, I've now experienced the issue, WITH the new push. Only seems to happen with more than one stream though.
unless anybody else has ideas, I might have to set the default tuner count to 1
I just had an idea, and I think it's something to do with the sid
attribute
multiple streams should definitely be possible, channels allows them and i haven't seen this happen at all when watching with their m3u implementation.
I'd be interested in seeing what url parameters they are passing
I think I was on the right track with the sid
attribute, I modified it with a time.time()
and that seems to have fixed it!
Anybody able to test?
Testing now. Will let you know how it goes.
It seems to be working better but now I am not getting any Content Description in Plex or in the WebUI
Go to the xmltv tab, clear cache, and update,
It's a known issue, I have to figure out the maximum amount of time I can get epg data for
So assuming the 'sid' fix is the trick, I think that it's essentially a client stream identifier, thus the reason the channel would switch
I tried using the xmltv UI to clear the cache but it didn't work. I ended up deleting the fhdhr.db file and restarting fhdhr_plutoTV and that worked. I put it in my 2am batch file that stops and restarts all my services and now deletes the .db cache file. A clunky work-around for now.
So far no channel changing and no looping of segments. However there seems to be more pixilation especially on the movie channels. Any suggestions for settings that may help with this?
Oof, you don't want to be deleting the database via cron, the new channels system depends on it
[plutotv]force_best
Any ideas why the WebUI is not clearing it out? I prefer it. Also once working how about a url to clear the cache so it can be automated.
WebUI works fine for me, you have to click the clear cache button, wait for it to say clearcache success, then click update, and again wait for it to say update success.
Then go to guide page and see the new data
Images uploaded in reverse order, smh
I think PlutoTV epg only provides 8 hours of data, so that kinda sucks
Also there already is an api url for doing so, it's how the webui works
http://ip:port/api/xmltv?method=clearcache&source=origin
The api isn't documented, because I'm not 100% sure about the structure yet
Closing this thread, there is a seperate thread regarding epg
seems there are some issues with how this handles pluto streams. i pick a channel to watch and almost always get that channel to start, but then after about 30 seconds it changes to some other random channel...