Opened 5 years ago

Closed 11 months ago

#12781 closed Bug Report - General (Unverified)

'OriginalAirdate' is incorrect following a 'RECORDING_LIST_CHANGE UPDATE' event

Reported by: andrew@… Owned by: Bill Meek
Priority: minor Milestone: unknown
Component: MythTV - General Version: Unspecified
Severity: medium Keywords: airdate originalaridate event
Cc: Ticket locked: no

Description (last modified by Bill Meek)

MythTV protocol correctly reports 'ORIGINALAIRDATE' for a recording. When the Event mechanism fires a program update event, it appears to provide ORIGINALAIRDATE as 'now' (which seems to be the default when creating a new programinfo item) rather than the original airdate from the recorded database.

This was originally reported as an issue with pvr.mythtv kodi front-end client (using 0.28) then 'worked around'.

I tried to find where the problem might be, but got lost in the mythtv code. Maybe someone here is interested and knows where to look...

Change History (6)

comment:1 Changed 5 years ago by Bill Meek

Status: newinfoneeded_new

Please mention the endpoint Kodi is using, for example: backend:6544/Dvr/GetRecordedList and any parameters that are sent with it (which seems to work for me, but the value is returned in AirDate?.)

comment:2 Changed 5 years ago by Mitch Capper <mitch.capper@…>

I don't think this has to do with the services API but myth protocol.

comment:3 Changed 5 years ago by Bill Meek

Agreed, but I'm asking Andrew to confirm, expecting that the Component should be changed (the Subject looks like it's referencing the internal protocol and I thought Kodi used the API.) Looks like it uses both 6543 and 6544.

comment:4 Changed 5 years ago by andrew@…

Confirming the kodi client uses both the services API (port 6544) and the mythv protocol (6543). Explains why I couldn't find where the 'event' mechanism was. Sorry this should have been tagged as mythprotocol not services API.

The kodi client is set up to read ProgramInfo? fields from the internal protocol when it receives an 'UPDATE' event. ( then

I've not trapped the packets myself but based on what @fetzerch posted and having reproduced the symptoms he reported myself (and fixed the problem with @janbar's updated code), I strongly suspect the internal protocol is reporting 'airdate' as 'date of airing' (or QDate()) rather than 'original airdate' in the programinfo following an UPDATE event.

This is an internal protocol so maybe it is intended operation, but it feels like a mistake to me.

comment:5 Changed 5 years ago by Bill Meek

Component: MythTV - Services API - BackendMythTV - General
Description: modified (diff)
Status: infoneeded_newnew

Andrew thanks for the update.

Not sure who to reassign this to based on the GoToDev list.

comment:6 Changed 11 months ago by Stuart Auchterlonie

Resolution: Unverified
Status: newclosed

Closing all old tickets in trac.

If your issue still persists, please open an issue in Github

and reference the existing trac ticket.

Note: See TracTickets for help on using tickets.