[Bug] No comskip chapter markers in 1.6.0 pre release + Titan (1 Viewer)

[HomeY]

I am now watching the video, and I am past the point of the comskip marker. Now when I bring up the 'info' OSD, I don't see the comskip marker. Is this because the progress bar is drawn over the top?

I assume so and have been noticing the same. Not sure if we ever showed 'past' markers in the timeline.

 

[Lbr_Lion]

Hi,

I did also some testing with MP1.5 and MP1.6 and can confirm that the comskip markers working correct in MP1.5 with Default skin and my own skin. (First time in info OSD and also in pause OSD for recordings and MyVideo). In MP1.6 it works as already reported (Only after displaying info OSD the second time and no markers in pause OSD)

'past' markers are also not displayed in MP1.5 and I assume this is intended. (I don't see the need to display past markers)

I noticed also an issue with the marker properties for TV and Video. According to Wiki, there are different properties for TV (#TV.Record.jumppoint/chapters) and Video (#jumppoint/chapters) but in the Default skin (MP1.6) the same are used (Video) and due to this when you play a video with markers and after that you play a recording without markers, still the markers of the video are displayed. (In MP1.5 different properties are used)

Cheers

 

[catavolt]

According to Wiki, there are different properties for TV (#TV.Record.jumppoint/chapters) and Video (#jumppoint/chapters)

This was changed in actual version, so the Wiki is uncorrect.
But as Mark already pointed out, this must be clarified at least in 1.7

 

[michael_t]

I did some research on this issue and found two bugs:

• Titan does use progress instead of tvprogress for the pause progress bar (this must be fixed in Titan's videoFullScreen.xml)
• the GUITVProgressControl code does not create the marker image in certain circumstances (this must be fixed in GUITVProgressControl.cs). With any window redraw (e.g. second opening of the OSD or toggle fullscreen or pressing "X" twice) the marker image is created and then the comskip markers are drawn.

I could create a JIRA issue for the second bug; the bugfix is quite simple and could be released with 1.7 (or a 1.6.1 bugfix version if there will be one). Or we rework the whole progress code and put everything together in one common progress control as supposed above. @Developers: What do you think?

Michael

 

[elliottmc]

I did some research on this issue and found two bugs:

• Titan does use progress instead of tvprogress for the pause progress bar (this must be fixed in Titan's videoFullScreen.xml)
• the GUITVProgressControl code does not create the marker image in certain circumstances (this must be fixed in GUITVProgressControl.cs). With any window redraw (e.g. second opening of the OSD or toggle fullscreen or pressing "X" twice) the marker image is created and then the comskip markers are drawn.

I could create a JIRA issue for the second bug; the bugfix is quite simple and could be released with 1.7 (or a 1.6.1 bugfix version if there will be one). Or we rework the whole progress code and put everything together in one common progress control as supposed above. @Developers: What do you think?

Michael

It may be that what we do is affected by the TV code freeze. So we would only be able to use a fix that had little or no impact on the TV code.

However, GUITVProgressControl is in the core MP code, so a fix here would be permitted.

If it was possible to fix the progress control to be common to TV/videos and include all of the necessary skin elements, this has to be a better fix, as long as it doesn't require any changes to the TV code.

I guess the big question is, if we go down the route of a total fix to make everything as clean and simple as possible, are you able/happy to do that ?

Regarding the comskip stuff not being shown if playback has got past that point, I think there are reasons why you would want to skip backwards, and I guess this is just a matter of which bit you draw on top, right?

 

[michael_t]

It may be that what we do is affected by the TV code freeze. So we would only be able to use a fix that had little or no impact on the TV code.
However, GUITVProgressControl is in the core MP code, so a fix here would be permitted.

The bugfix has nothing to do with TV code, it is plain GUI code.

If it was possible to fix the progress control to be common to TV/videos and include all of the necessary skin elements, this has to be a better fix, as long as it doesn't require any changes to the TV code.
I guess the big question is, if we go down the route of a total fix to make everything as clean and simple as possible, are you able/happy to do that ?

One thing to consider (besides the question who does it) is the fact that we might break compatibilty for all skins using the (then legacy) tvprogress control.

Regarding the comskip stuff not being shown if playback has got past that point, I think there are reasons why you would want to skip backwards, and I guess this is just a matter of which bit you draw on top, right?

This is indeed a matter of drawing order. The tvprogress control first draws the comskip markers and then the progress bars. This could be modified so that the progress bars do not overwrite the markers (maybe configurable).

Michael

 

[elliottmc]

It may be that what we do is affected by the TV code freeze. So we would only be able to use a fix that had little or no impact on the TV code.
However, GUITVProgressControl is in the core MP code, so a fix here would be permitted.

The bugfix has nothing to do with TV code, it is plain GUI code.

That's what I was hoping. So hopefully that could be fixed without too much trouble?

If it was possible to fix the progress control to be common to TV/videos and include all of the necessary skin elements, this has to be a better fix, as long as it doesn't require any changes to the TV code.
I guess the big question is, if we go down the route of a total fix to make everything as clean and simple as possible, are you able/happy to do that ?

One thing to consider (besides the question who does it) is the fact that we might break compatibilty for all skins using the (then legacy) tvprogress control.

Yes, that is a bit of a worry.

Regarding the comskip stuff not being shown if playback has got past that point, I think there are reasons why you would want to skip backwards, and I guess this is just a matter of which bit you draw on top, right?

This is indeed a matter of drawing order. The tvprogress control first draws the comskip markers and then the progress bars. This could be modified so that the progress bars do not overwrite the markers (maybe configurable).

Well, if we could change the order of drawing, that would definitely be acceptable.

What about the pause OSD's not showing comskip info? I guess that is a separate issue, so it looks like we have three bugs.

1. comskip info not shown the first time you open the OSD
2. comskip info hidden by the progress bar
3. comskip info not shown in the pause OSD

Is that a fair assessment of the situation?

Thanks,

Mark

 

[michael_t]

What about the pause OSD's not showing comskip info? I guess that is a separate issue, so it looks like we have three bugs.

1. comskip info not shown the first time you open the OSD
2. comskip info hidden by the progress bar
3. comskip info not shown in the pause OSD

Is that a fair assessment of the situation?

Thanks,

Mark

I would say this is correct, if you rate 2. as a bug and not as a feature. I am not sure if the reverse drawing order is really better, because then there might be complaints like "I cannot see the progress bar because it is hidden behind a comskip marker". I would let this open for now and later add a "ShowMarkersOnTop" (or something like this...) option to a new consolidated "progress" control.

So I would propose to make a JIRA bugfix issue and a GIT branch for the 1. bug, another JIRA bugfix issue for the 3. bug and - if we agree upon this - a JIRA rework issue for a consolidated progress control.

Michael

 

[elliottmc]

What about the pause OSD's not showing comskip info? I guess that is a separate issue, so it looks like we have three bugs.

1. comskip info not shown the first time you open the OSD
2. comskip info hidden by the progress bar
3. comskip info not shown in the pause OSD

Is that a fair assessment of the situation?

Thanks,

Mark

I would say this is correct, if you rate 2. as a bug and not as a feature. I am not sure if the reverse drawing order is really better, because then there might be complaints like "I cannot see the progress bar because it is hidden behind a comskip marker". I would let this open for now and later add a "ShowMarkersOnTop" (or something like this...) option to a new consolidated "progress" control.

So I would propose to make a JIRA bugfix issue and a GIT branch for the 1. bug, another JIRA bugfix issue for the 3. bug and - if we agree upon this - a JIRA rework issue for a consolidated progress control.

Michael

Agreed! Although for 2, unless the commercials are really long, you kind-of know where the progress marker is approximately, and if you have comskip information, you'll probably hit 'skip' to get past them anyway, so I don't see the problem. But as things are now, if you wanted to skip backwards to the last commercial break, you have no visual cue for this.

 

[mattjcurry]

What about the pause OSD's not showing comskip info? I guess that is a separate issue, so it looks like we have three bugs.

1. comskip info not shown the first time you open the OSD
2. comskip info hidden by the progress bar
3. comskip info not shown in the pause OSD

Is that a fair assessment of the situation?

Thanks,

Mark

I would say this is correct, if you rate 2. as a bug and not as a feature. I am not sure if the reverse drawing order is really better, because then there might be complaints like "I cannot see the progress bar because it is hidden behind a comskip marker". I would let this open for now and later add a "ShowMarkersOnTop" (or something like this...) option to a new consolidated "progress" control.

So I would propose to make a JIRA bugfix issue and a GIT branch for the 1. bug, another JIRA bugfix issue for the 3. bug and - if we agree upon this - a JIRA rework issue for a consolidated progress control.

Michael

The drawing order is intentional because the most important component, which is the progress bar, is always on top. If the skin devs want to allow the markers to be seen through the bar, they can either adjust the height of the progress bar so it does not fully cover the markers, or they can make the png semi-transparent. The idea is to leave it up to the skin devs. I am not sure that you are any better off if you change number 2. At least the way it is, you know that the progress bar will be seen.

I do not have the screen shots handy, but if you look through the original threads, you can see how neat it looks for avalon with the current layout. If number 2 is a bug, then it should be a titan skin bug and not a core bug, however I got the impression that the titan guys did not want to change the progress bars to make them semi-transparent.

Matt