How to tell if guide update has started/completed

oldguy327

I like the new interface. But when I update the guide data I am unable to tell if the updated ever started or completed. I added a network monitor to LMDE7 so that I can see when network traffic starts and stops, but I feel like it would be better for users if there was some indication of the guide update status in the update button. Maybe a last updated date or update started/update processing/update complete. Would this be possible?
Thanks,
Oldguy327
LMDE7/Mate, TVHeadend updated 26JUL26 (can't get to the DVR right now)

DeltaMikeCharlie

oldguy327 I like the new interface. But when I update the guide data I am unable to tell if the updated ever started or completed.

Were you able to do this with the Classic UI? If so, where did this information show?

oldguy327 I added a network monitor to LMDE7 so that I can see when network traffic starts and stops,

Where do you get for EPG data from? XMLTV?

oldguy327 Maybe a last updated date or update started/update processing/update complete. Would this be possible?

That information does not currently appear to be exposed via the API. However, the data is stored in the EPG 'parent object'.

The 'last updated' timestamp and grabber name can be obtained for each EPG entry.

Here are some quick diagnostics that I performed on a modified test system:

    {
      "eventId": 10309,
      "episodeUri": "crid://seven.net.au/uKvou3iJltaPmtuN",
      "serieslinkUri": "crid://seven.net.au/uKvou3iJ",
      "channelName": "7 Sydney",
      "channelUuid": "ecbeeb3c1bd1abacf0780cff39604533",
      "channelNumber": "70",
      "grabber_name": "EIT: EPG Grabber",     <======
      "grabber_id": "EIT: EPG Grabber",       <======
      "grabber_type": 0,                      <======
      "last_updated": 1785446410,             <======
      "start": 1785441573,
      "stop": 1785454200,
      "title": "Sunrise",
      "subtitle": "Wake up to a better breakfast with Natalie Barr and Matt Shirvington for all the latest news, sport and weather.",
      "subtitled": 1,
      "genre": [32],
      "nextEventId": 5909
    },

Each time the EPG grabber is run, the EPG entry is 'updated' regardless of if any EPG data actually changed.

The EPG Grabber does not have a timestamp for each run, only the timestamp for each individual EPG entry. It may be possible to extract this information from the log, but only for the current session.

Having the timestamp for each individual entry could be useful for spotting entries that have not been updated recently.

Maybe a new API function could be written to return the high/low timestamps for a given set of EPG entries. Or maybe the new WebUI could perform that analysis as it obtains the EPG data.

Maybe 'last run' property could be added to the EPG grabber record.

@oliver - Do you have an opinion?

DeltaMikeCharlie

During my morning exercise, I was thinking about this issue and I have a few more thoughts:

Simple/Minimal Change - Back-end and WebUI

For the EPG, we could add lastUpdated and grabberUuid properties. These are already in existing data structures and easy to add to the existing EPG API output.

The lastUpdated property will allow the UI to provide a simple "Last updated nnn minutes ago." message in the EPG details drawer.

With a little more effort, the grabberUuid property will allow the UI to provide a slightly more detailed message like "Last updated nnn minutes ago by {grabber_name_here}." message in the EPG details drawer.

    {
      "eventId": 4118,
      "channelName": "ABC SYDNEY",
      "channelUuid": "bea5fbd1126a6166f11902def6c0227e",
      "channelNumber": "25",
      "lastUpdated": 1785445486,
      "grabberUuid": "478b9f70ee8c6b70a1d9efb75a170154",
      "start": 1785450600,
      "stop": 1785459600,
      "title": "Mornings with Hamish Macdonald",
      "subtitle": "Keep informed, amused, entertained and inspired each weekday morning with local Sydney stories, political insights, your opinions and engaging discussions.",
      "nextEventId": 4284
    },

A little more effort - WebUI

These 2 properties will also allow the UI to evaluate the EPG data that it receives and keep track of the high/low timestamps by grabber module or maybe even channel.

These timestamps could be used as a proxy for the last time the grabber module was run and displayed on the home dashboard. Perhaps with a warning if the update was too long ago.

Moderate Change - Back-end and WebUI

Add 3 new timestamps to each EPG grabber module: last_run_started, last_run_finished and last_record_updated.

If last_run_finished < last_run_started, the grabber is currently running.

If last_record_updated < last_run_started the grabber found no data during the last run.

The EPG grabber logic would have to be updated to track and store this data. Because it would require an idnode to be saved, a comet message should automatically be issued when these values are updated.

This change would provide a reasonably comprehensive overview of each EPG grabber directly from the back-end without the WebUI needing to do much more that displaying the results. Perhaps a new grabber status summary page could be created to display this data.

A lot more effort - Back-end and WebUI

Add the abovementioned properties to every service/channel object allowing for a more detailed analysis of EPG updates. This would be overkill in my opinion. However, with some extra WebUI work, this analysis could also be derived from the added lastUpdated and grabberUuid properties.

oldguy327

DeltaMikeCharlie thank you for your quick response, sorry for my slow response.

In the Classic UI I used the debug window at the bottom of the screen to watch for the completion of the EPG grabber. I am using Schedules Direct for my EPG, but the process was very similar when I was using zap2epg in the past. When the EPG script completes the last message is about scheduling the saving of the EPG data.

I only update the guide once a week grabbing 10 days of guide data. I can watch the This Weeks Recordings section on the Home screen and when it shows 10 days of guide data I know the guide has been downloaded. Crude, but it seems to work.

Thanks for looking into this,
Oldguy327