Reloading custom m3u on server update?

both of my channels instances updated earlier today (i'm using my mapping setup so i have a backend and a frontend). the frontend has (unbeknownst to me) had zero channels available since about 1pm today, because when it updated and restarted it apparently couldn't find any channels.

the backend updated around noon, the frontend about an hour later. it seems that when the frontend updated, that's when the zero channels thing started (when i go into the web interface, it shows all sources as having zero channels). a few recordings were missed because of it. a simple "reload m3u" fixed it.

the question is: any ideas why would this happen? i can see how it would happen if both were reloading at the same time, but in this case there was a full hour inbetween each one updating...

further examination shows that i had no issues at 12:30 or so accessing the backend for a recording...so it was up and running immediately after the upgrade. that means that when the frontend updated, it seems to have started with 0 channels available and never actually loaded the m3u.

is it possible this is an issue on startup? is there any way to troubleshoot this to try to figure out exactly what went wrong here?

it seems this must have been an example of a timeout or access denied on loading my channels mapper playlist...but the question is, why would it not try to reload it when it sees that there are zero channels? i reloaded the m3u and that immediately fixed the issue...shouldn't the server try to reload on its own in that case?

this doesn't seem exclusive to just my channels instances. my dizquetv channels won't play now either. something definitely got screwed up on the upgrade...the server can see the channels (says 10 channels) but the app won't play them (source says 0 channels and tuning to them manually gives me "playback failed" with no errors in the log).

I've added this behavior in the next pre-release.

1 Like