-
-
Notifications
You must be signed in to change notification settings - Fork 6.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
change season/episode infolabels for specials #17408
Conversation
change season/episode infolabels for specials
change season/episode infolabels for specials
@razzeee , @ronie , @ksooo This is impacting PVR recordings. The documentation says S0+E0 is ok for invalid for PVR Recordings but they are now displayed as S0 because of the = test |
i'm not really familiar with pvr, can you please point me to this documentation? |
|
thanx! i've only now found out that PVR uses their own code for season / episode infolabels: xbmc/xbmc/pvr/guilib/guiinfo/PVRGUIInfo.cpp Lines 573 to 583 in dfad22e
xbmc/xbmc/pvr/guilib/guiinfo/PVRGUIInfo.cpp Lines 565 to 572 in dfad22e
since i haven't touched that part, i wonder how this PR could have an effect on PVR... |
PVR has own code part for EPG, but uses videoinfotag code path for recordings. Thus, changes in the video path can affect recordings. |
I suggest to change PVR API to not allow 0/0 to signal "not available" any longer. This means, to update the API documentation and to adapt all PVR add-ons. As I'm not available for doing this during the next couple of months due to time constraints, somebody else would have to step up. |
@ksooo is that feasible without knowing what the backend is sending? I checked pvr.hts and I see
Rather than adding a condition to each PVR could we not just modify how they are copied https://github.com/xbmc/xbmc/blob/master/xbmc/pvr/recordings/PVRRecording.cpp#L78 to
Also is memset required on any of the PVR types functions at this time? If not I could flag issues on the official addons that still use them (like mine) to remove it. |
It is feasible for the maintainer of the soon, yes. If there is no maintainer, the add-on will die, former or later.
We should fix the route cause, which is bad API design here, not hack around the actual problem, just because the latter is less effort.
If the addon creates the struct, then it must initialize its members - 'memset' works for this, although better approach is 'TYPE foo = {};' - so there is no need to file issues for add-ons still using memset. |
Sorry I misunderstand your first comment I thought you wanted someone other than the maintainer to make this change. The recent update to pvr.hts shows how difficult that would be. My comments about memset were more about how to factor this change in with PR1645 looming but now I see that likely won't be a Matrix issues anyway. I think we can close this discussion here as I opened a PR for your recommendation. |
change season/episode infolabels for specials
change season/episode infolabels for specials
change season/episode infolabels for specials
change season/episode infolabels for specials
change season/episode infolabels for specials
change season/episode infolabels for specials
change season/episode infolabels for specials
the PR removes the odd season/episode numbering we use in infolabels for episodes that are specials.
before:
after:
(the same change applies to VideoPlayer.Season / VideoPlayer.Episode)
fixes #17402
for skinners / addon devs it's much easier to work with those infolabels this way.