Thanks, that’s exactly what I was getting.
Going crazy trying to figure out what I messed up. I can relax a bit until I learn more.
I appreciate the response
It's the DVR that's not correctly getting the new data....try running 'Re-Download entire guide'
1 Like
Tried redownloading.
Clicking on the TRASH icon and reentering “http://127.0.0.1:8080/epg.xml” worked however
This worked in my case.
For what it's worth, the record function is displayed and works fine in Pluto channel content, using the tvOS version of Channels DVR.
2 Likes
related question: if i add a source and then remove it, those channel numbers seem dead forever (i.e. it seems to start at 9000 for the first source you add, but then if you remove that and add a different source it starts at whatever higher number it would have if those channels were still there). is there a way to clear that cache and go back to 9000 until an allowed start number override per source is finished?
Are you on the latest build? The bug you're describing was fixed a few days ago.
me? i thought i was, i'll do an update check and confirm...
edit: Version
2020.11.18.0042
if you were talking about the channel numbers not resetting when a source is deleted, i'm definitely still seeing that on the latest build. i just did a forced update and deleted and re-added pluto, and i'm up over 10000 in the channel numbers now...
Okay I see what happened. Will be fixed in next build, but you may need to add a source with the same name and remove it to clear the old entries created.
1 Like
OK, the newest version supports setting the starting channel number. Use the START_CHANNEL_NUMBER env var to set it.
1 Like
Is there a reason you're not using the channel-number tag to set your own numbers?
@tmm1, is there a reason you went with the channel-number tag instead of tvg-chno or tvh-chnum?
this is about the container that grabs the pluto M3U and EPG.
No reason. tvg-chno also works.
Thanks. I'll have to look into this when I try to setup a system for my parents, and put their cameras in the TV feed.
I've removed this option. It was a naive implementation as the channel numbers will change as the channels update from Pluto.
We'll address custom channel number picking in the future in some way. As an alternative, you could always use the m3u generated and manually edit it with channel numbers and add an m3u source with the text based option.
1 Like
Instead of using the gui text option for entering an m3u, I'd like to use a URL and point it to a m3u file on my hard drive. I've tried a few combinations of syntax that should meet the file URI scheme for Windows, but the channels are not being read from the m3u file. 1. Can channels read a local m3u using the URL option? and 2) if so, can someone point me to the correct syntax for Windows?
In my test, I have a test.m3u file residing on the root level of my Channels DVR (Windows) server.
Thanks,
Tim
Edit: Found this in the log file, sounds like this method is not supported (yet): 2020/11/18 14:31:19.319664 [ERR] Failed to request m3u: Get "file:///c::/test.m3u": unsupported protocol scheme "file"
sad face.
this was more about trying to ensure (for me anyway) to make sure they always started in the same spot rather than worrying about what each number below that was, to increase the WAF. if she doesn't have a spot she can always go to find pluto (9000 for example, if that's what i'm using as the start channel), she's never going to bother with it.
So I finally have everything working with my camera M3U playlist. I've added each camera feed individually, and then a live quad feed. All is working as expected except for on the android app. Not too worried about some of the placeholder images not showing up, but my quad feed (channel 9004) does even show up in the guide or on-now section. See images below. Is it just not fully functional with the android app at this stage?
Admin Guide View:
Admin On Now View:
Channel 9004 Streaming:
Missing Channel 9004 on Android App:
2 Likes
Perhaps it is not favorited on Android? Can you submit diagnostics from the Android app.