Tvc-guide-stationid=sometimes-bug?

Playground
#1

Still new to Channels and learning the tricks and quirks. Apologies if this already known and welcome any pointers. Put together a tuner for the updated science channel / discovery rebuild and was surprised to find that was easy compared to incorporating the corresponding EPG data.

Having seen other projects re-injecting XML guide data back into Channels, I did the same. Certainly works, but feels wrong for many reasons. Looking at the M3U data, tvc-guide-stationid= caught my eye. Found the Custom Channels FAQ indicating it pulled in the correspoding EPG-- great! Pretty sure I created a custom M3U where it worked and eliminated the feedback-XMLTV dependence.

Fast-forward: while cleaning up code (and maybe pushing my luck by putting my Science at 6110 to replace the broken one), guide data disappears. Not only does it disappear, but hours of effort (excluding XMLTV injection) would not restore it. A final back-to-basics brought it back. Wondering if there is a bug that causes it the tag to fail in certain situations.

My impression is that if a custom channel M3U contains any channels without tvc-guide-stationid= then it fails for all channels. After my initial success, I consolidated all my custom M3Us into a single source. Most have no EPG data by design.

Reviewing past forum posts, appears folks have had success and failure with this tag. Interested if anyone else can confirm/deny this curious seeming behavior. Works fine once I moved Science to its own custom M3U. Thanks.

#2

If the /devices endpoint shows Lineup:X-M3U then the tag should work on any entries which have it.

It is possible there's a bug as the feature is not widely used.

#3

Both the current-working and previously-non-working customs are X-M3U. Apologies for the dubious formatting. The "fixup" M3U (with science+locast 23.4) was pulled from channels own M3U and the channels updated to 8000/8001. When consolidated into my custom999x M3U, EPG lookup fails.

With some idea what to look for, can recombine tomorrow and re-verify results. Assuming duplicate results, any other data required besides the devices output from the consolidated M3U object?

Working separate custom M3U (called "Fixup"):

Provider    "m3u"
DeviceID    "M3U-Fixup"
FriendlyName    "Fixup"
ModelNumber    "HDHRCOMPAT-1"
Lineup    "X-M3U"
Channels:
  ID    "8000"
  GuideNumber    "8000"
  GuideName    "SCIENCE"
  HD    1
  Station    "57390"
  Logo    "https://tmsimg.fancybits.co/assets/s57390_ll_h15_ac.png?w=360&h=270"

  ID    "8001"
  GuideNumber    "8001"
  GuideName    "COMET-dup"
  HD    1
  Station    "52331"
  Logo    "https://tmsimg.fancybits.co/assets/s97051_h3_aa.png?w=360&h=270"

Older custom channels (called Custom999x-- EPG fails when combined):

Provider    "m3u"
DeviceID    "M3U-Custom999x"
FriendlyName    "Custom-999x"
ModelNumber    "HDHRCOMPAT-1"
Lineup    "X-M3U"
Channels
  ID    "rewind9991"
  GuideNumber    "9991"
  GuideName    "Rewind: CSI"
  HD    1

  ID    "rewind9992"
  GuideNumber    "9992"
  GuideName    "Rewind: Cutthroat"
  HD    1

  ...3 more almost identical...
#4

Late and bit slow. Realized that since the working custom M3U has two entries, my theory is easily tested. Removed the tvc-guide-stationid= from the second channel. Reloaded the M3U and the guide was still there-- for both channels. This triggers a memory and think the EPG may get buffered beyond manual reload changes that should add/remove it.

Will check again tomorrow, but more confident this may be is a legit issue. Curious if both guides disappear after the existing EPG data expires. Will update when more data available.

#5

Figured it out. When you have custom channel(s) based exclusively on an M3U (no external XMLTV EPG data), the DVR caches any EPG data (from tvc-guide-stationid tags) when the source is added. After that, adding/changing/removing tvc-guide-stationid tags for the custom channels followed by a "Reload M3U" has no effect on the EPG making it seem broken. (Icon and label changes do take effect on reload.) You must manually remove the source and then re-add to flush and reload the EPG data. (For custom channes with XMLTV EPG, there is an explicit reload option.)

Fairly simple workaround, but probably worthwhile fixing the underlying bug to avoid frustration for other users.

#6

One more little quirk-- if you modify channel numbers and then reload the M3U, the EPG data does not move to the updated channel. Removing and re-adding the M3U source fixes this issue as well.

To get my temporary science replacement onto 6110, had to hide 6110 in Philo and then delete/re-add a custom channel with science at 6110 and tvc-guide-stationid="57390". (The same technique also worked to replace a locast channel with an alternate stream source.)

#7

When you're modifying and changing sources, guide data, and channel mappings, Channels' guide database can easily get in a "confused" state. To make sure changes are properly reflected, take these steps:

  1. Make your source, guide, or channel number changes
  2. In the DVR web UI, go to Settings > Guide Database > Maintenance > Delete and Recreate Database
  3. Restart the DVR server (not necessarily the computer itself, just the server process)
  4. Restart your client apps (on Android, this is a Force Stop; on Apple it's a swipe to close the app)
1 Like
#8

Great feedback. I was pleased that, excluding the need to remove/re-add custom channels, the the guide data seemed to remain correct throughout my experiments. Nonetheless, a rebuild sounds like good practice after extensive guide manipulation.

Seems like #2 should be something that optionally happens at app launch. If I am restarting the container for whatever maintenance reason, why not just rebuild the DB during that process? Prior to app launch, can the appropriate db files simply be removed so the app rebuilds them on launch? Add an extra #ExecStartPre=rm (officially-santioned-file-pattern).db and call it a day?

Thanks for the info!

#9

Since the database creation involves re-downloading weeks of guide data, such an action at startup would cause the server to seem to hang at startup.

In regular use, there is no need to go nuclear on the database as it is pruned and updated daily; wiping it out at every startup wouldn't add any real benefit, but would add to a negative experience.

#10

Makes perfect sense. Appreciate the additional context. Thanks.