[fixed] TV recordings time progress not remembered (1 Viewer)

[Sebastiii]

The issue appear only in singleseat mode and not in multiseat

 

[elliottmc]

I think i know what happen
i will supply bin tomorrow with a fix

Can you explain why it is working perfectly for me?

Even if I start a recording on one PC, stop it and resume on another, it is still working 100%. I am totally confused by this, although we have very limited testing. Would probably help if all the people looking at this thread could take the time to report in and tell us whether it works for them.

 

[elliottmc]

The issue appear only in singleseat mode and not in multiseat

You are absolutely right. I can reproduce this in singleseat.

If I start a recording on the client and then resume it on the server, it is fine, so it is only on the server that it isn't storing the time.

Definitely confirmed, so I will mantis this now.

 

[elliottmc]

Now in mantis. Big thanks to @AtTimesPerplexed for a good bug report, and sorry for not confirming it earlier.

 

[Sebastiii]

After many hours resetting the master branch to various commits to try and find where it breaks, I think I have found the culprit.

GITHUB:Fix BASS and VideoPlayerVMR9

Builds made before this commit work normally and builds after do not. I think the problem is MP not writing the data, rather than not reading it.

If I use a working build and watch a recording for a few minutes then stop, that data is saved. If I then install a non-working build, the resume dialog pops up with the correct resume time from the working build, but any new resume data is not saved instead it will ask to resume from the same time as the working build saved. Hope that made sense?

Thanks to nail down to that commit
@elliottmc, thanks for confirming and mantis.

I have updated the mantis with a branch with a fix but you can try attached core.dll for testing if it's ok for both of you
Seb.

 

[AtTimesPerplexed]

Fixed.

 

[markus_g]

I can also confirm that resume works again.

Regards,
Markus

 

[elliottmc]

Great. @Sebastiii - is there any risk that fixing this could cause other problems? What about radio recordings?

If we can confirm that there is no risk of regression, then this can be safely merged to master for inclusion in 1.4.0.

 

[AtTimesPerplexed]

Radio recordings are working as well

 

[Sebastiii]

Great. @Sebastiii - is there any risk that fixing this could cause other problems? What about radio recordings?

If we can confirm that there is no risk of regression, then this can be safely merged to master for inclusion in 1.4.0.

The first check code was added for music with audio/video, the new patch handle it only for music, so we are safe
In other word, the mediatype will change only when it comes from music