MP2 - V2.5 TVMosaic Provider for MP2 (3 Viewers)

[pbarvinko]

I believe that's already the case. If there is a conflict or an error then TVMosaic add_schedule API command returns an error.

 

[ge2301]

I believe that's already the case. If there is a conflict or an error then TVMosaic add_schedule API command returns an error.

But does it also differentiate between conflict types? I saw in the api return messages only “no free tuner” and “error”. Let’s assume there are enough tuners, but two series schedules contain the same program, just on different channels. Does it provide a warning? We want to improve the MP2 conflict management in a way, that those points are recognized and can be resolved. the MP2 GUI should report to the user “same program already scheduled” and options “record anyway” and “resolve” (according the previously set criterias one will be recorded and the other cancelled. Criterias are earlier airing, HD before SD, …)

But if TVMosaic does already have the features on board we might save time and potential conflicts in communication between TVMosaic and MP2.

 

[ge2301]

@morpheus_xx @Brownard
While overworking the media info screens I realized, that the infos are shown correctly for recordings done with TVE3 (own TV engine):

• AspectHeight and AspectWidth have values
• RecordingTime as part of MediaAspectWrapper has a date

For all recordings with TVMosaic some information are not detected correctly and I'm not sure about the root cause.

• AspectHeight and AspectWidth are empty in MP2. MediaInfo says:

• RecordingTime as part of MediaAspectWrapper is empty. Only the time as part of RecordingAspectWrapper is ok, but I do not want to refer to it in the general info screens, because there could be users w/o TV plugin.

 

[AdHu86]

Is there a new test build with the latest changes? The last one in first post is from 7th January. Maybe I missed something, you all seem able to test it

 

[Brownard]

AspectHeight and AspectWidth are empty in MP2. MediaInfo says:

We are getting the info via the TvMosaic API so don't have access to the video files directly so can't just pass them through MediaInfo. I think MediaInfo does have some support for reading files from a stream so we could potentially start a download of a file and pass it in, but I don't know what the performance implications would be, e.g. if it decided it needed to download the entire file every time.

RecordingTime as part of MediaAspectWrapper is empty. Only the time as part of RecordingAspectWrapper is ok, but I do not want to refer to it in the general info screens, because there could be users w/o TV plugin.

I've pushed a change for this. There was a property returned from the API called 'CreationTime' but it was always 0 for me (perhaps @pbarvinko could shed some light on this?) , instead I've populated it with the schedule start time.

Maybe I missed something, you all seem able to test it

We are building it ourselves from the source . @ge2301 are you able to create a new installer to test? I did try merging the changes back into the original branch but it still contained @morpheus_xx 's changes so I didn't in the end.

 

[ge2301]

We are getting the info via the TvMosaic API so don't have access to the video files directly so can't just pass them through MediaInfo. I think MediaInfo does have some support for reading files from a stream so we could potentially start a download of a file and pass it in, but I don't know what the performance implications would be, e.g. if it decided it needed to download the entire file every time.

For now I'll add visibility conditions in xaml, so at least no gaps or incomplete infos are shown in GUI without existence of AspectWidth or AspectHeight. Downloading the file seems indeed difficult considering long recordings

I've pushed a change for this. There was a property returned from the API called 'CreationTime' but it was always 0 for me (perhaps @pbarvinko could shed some light on this?) , instead I've populated it with the schedule start time.

Thanks

 

[morpheus_xx]

I did try merging the changes back into the original branch but it still contained @morpheus_xx 's changes so I didn't in the end.

I think it will be better just to keep the MDE branch and if needed I can port over the smaller changes I made.

 

[pbarvinko]

I've pushed a change for this. There was a property returned from the API called 'CreationTime' but it was always 0 for me (perhaps @pbarvinko could shed some light on this?) , instead I've populated it with the schedule start time.

From what I see in the code creation_time is not used at all. Honestly, I do not even remember why it was introduced.
I think that start_time shall be used here instead.

 

[pbarvinko]

But does it also differentiate between conflict types? I saw in the api return messages only “no free tuner” and “error”. Let’s assume there are enough tuners, but two series schedules contain the same program, just on different channels. Does it provide a warning? We want to improve the MP2 conflict management in a way, that those points are recognized and can be resolved. the MP2 GUI should report to the user “same program already scheduled” and options “record anyway” and “resolve” (according the previously set criterias one will be recorded and the other cancelled. Criterias are earlier airing, HD before SD, …)

But if TVMosaic does already have the features on board we might save time and potential conflicts in communication between TVMosaic and MP2.

TVMosaic has a built-in timer conflict management, although somewhat limited. It recognizes that programs overlap on the same tuner and in this case searches a free tuner where it can put this timer on. The fact that a particular program is already scheduled as part of another schedule is not taken into account. When there is a conflict then add_schedue only returns a boolean flag. The actually conflicting timers can be obtained by calling get_recordings (bad name it actually returns timers) and examining is_recording_conflict flag on a timer.

 

[ge2301]

I think it will be better just to keep the MDE branch and if needed I can port over the smaller changes I made.

Can you transfer the changes related to recording genre if still compatible. Those are missing yet. Thanks.