Opened 8 years ago

Closed 8 years ago

#10748 closed Bug Report - General (Feature request without patch)

MythWeb does not correctly update recording detail or listing when "record only this showing" is selected

Reported by: SingingDwarf <mythtv-trac@…> Owned by: Rob Smith
Priority: minor Milestone: unknown
Component: Plugin - MythWeb Version: 0.25-fixes
Severity: low Keywords:
Cc: Ticket locked: no

Description

Start at Program Listings page.

Click on a program title, which takes you to the Program Details page for that program.

Select "Record Only This showing" under "Schedule Options" and then click on "Update recording settings"

The page reloads, but "Schedule Options" now shows the "Don't record this program" (rather than the previously selected) radio button selected and the program title is not outlined in solid green, which it should be to signify that the program is scheduled to record.

If "What else is on at this time?" is immediately selected after the page has completed reloaded, the user is returned to the Listings page and the program is again not outlined in solid green.

If either the Program Detail or the Listings pages are reloaded, the program title is correctly outlined in green, showing that the program will be recorded.

This issue can also (sometimes) be observed to occur selecting other options, e.g. "Record at any time on channel xxx" or "Record at any time on any channel".

Is it possible that the scheduler is updating the database more slowly than the webserver is serving the MythWeb pages - and thus the database holds old data when served up via MythWeb?

Tested in Chromium and IE8

Change History (1)

comment:1 Changed 8 years ago by sphery

Resolution: Feature request without patch
Status: newclosed

If the backend is eventually doing the right thing (as your description makes it sound like), this is exactly as you theorized--MythWeb is loading the page before the scheduler run completes and, therefore, before the program's status has changed.

Some pages in MythWeb have been converted to wait for the backend to send a message saying rescheduling is complete. Others have not--in some cases because this waiting may actually be worse than returning control and showing soon-to-be-outdated information because scheduling can take a long time (10s of seconds or even minutes) for some users.

For now, I'm closing this as a feature request without a patch. If someone would like to create a patch, we can reopen the ticket.

Note: See TracTickets for help on using tickets.