DVR: Join film broadcast in multi parts

[afullmark 20]

Thought it would be best to make this a feature request: https://emby.media/community/index.php?/topic/50565-multi-part-movie-with-gap-in-the-middle-how-would-emby-deal/&do=findComment&comment=483904

 

Manually setting times would be an option. Or an option to auto join two recordings. In this case the guide showed the two halfs plus the break in the middle: so could emby perhaps auto join these two parts if they were selected in the guide with, say an advanced option to join? Not sure how this would technically affect subtitles or audio; messing with .ts can alter timings and even drop subtitles as .ts to mkv has shown.

 

Could this be a future emby enhancement: selecting the two parts in the guide and then some join option in advanced settings? Messing with .ts can cause issues: dropped subtitles or timing issues.

[afullmark 20]

Had a further thought on this; and as ffmpeg manipulations of .ts cause some trouble – 

Even this doesn't work well: ffmpeg -ss 00:02:45 -i Alice\ in\ Wonderland\ \(2010\).ts -t 01:40:59 -c copy -copy_unknown -map 0 out.ts

 – how about allowing this multipart broadcasts to be selected and recorded and identified as one movie, then saved using the existing stacking method (all selectable in DVR settings):

 

The English Patient (1996)-part1

The English Patient (1996)-part2

 

Then there is not mucking around with ffmpeg; as I know .ts to mkv has issues too. 

Edited September 5, 2017 by afullmark

[afullmark 20]

@@Luke or @@ebr any word on giving this a thought?

[ebr 16184]

We consider everything.  What has to be weighed here is how often does this happen against how complex would the interface to make it work be and, thus, how would people even know how to do it and that they could do it and would they go to the trouble to do it...

 

So, if the need and complexity of this feature caused it to be used only, say, 1% of the time, then we probably have other items to focus on first .

[afullmark 20]

We consider everything. What has to be weighed here is how often does this happen against how complex would the interface to make it work be and, thus, how would people even know how to do it and that they could do it and would they go to the trouble to do it...

 

So, if the need and complexity of this feature caused it to be used only, say, 1% of the time, then we probably have other items to focus on first .

Very understandable. Thank you.