Movie keeps "crashing" Roku (transcoding cache issue?)

[jbscout 1]

I added MovieA to my collection (as a *.mkv)  and played it (successfully) via Roku.  

I assume there was some transcoding (to convert to MP4) done by the server (a PC).

 

Unfortunately, I had messed up the DVD->MKV coding of MovieA (wrong audio & subtitles tracks).

So, a day or so later, I recoded them (as MKV) and did an in-place swap on the server (deleted Old MKV and copied in New MKV, same filename)

 

Now, when I go to play MovieA via Roku I get the loading screen, the bar goes 25-33% across the screen, stops and Roku "crashes" back to the MovieA info page (the one where you have "Play," Play from scene", etc.).

Other movies play just fine.

 

Enough time and manual server manipulation have passed that I've done "Clean Database", "Scan Media Library" etc. a number of times.

 

I am guessing (but not sure) there may be some old trasncoded crap in the server's cache that it is trying to resume, but since the movies (old vs. new) aren't actually the same the transcoding fails.

 

Is there a way for me to clear that cache?

 

Is there another likely cause for the error?

 

Thanks

 

 

 

 

 

transcode-ed7f1190-0310-487b-ae42-20d8dd60e9c4.txt

Edited July 23, 2016 by jbscout

[Luke 36991]

Hi, there is no transcoded cache. Sorry to hear about your troubles. The best thing to do is supply the info requested in how to report a media playback issue, and then we'll take a look. Thanks!

[Waldonnis 148]

I've noticed that when I swap a file out with the exact same name and container (often MKV) but with different audio tracks, the server never picks up the media file change.  Apologies for not reporting this sooner with logs (been busy), but I have found a workaround that you can try in the meantime.  Create an empty SRT (text) subtitle file for the movie in a language you wouldn't ordinarily care about (e.g. Amadeus.chi.srt), then rescan the library.  The server should pick up the audio changes as well during that scan, so after you've verified it, you can delete the empty subtitle file you created and rescan/clean. 

 

I've been doing a lot of audio track swapping in my files lately, so I've run across this as well.  I happened on that workaround by accident when I forgot to copy a new forced subtitle file for a re-encoded movie.  It seems swapping containers (or really altering the filename) or adding external subtitle files forces a fresh ffprobe on the media file, but if the filename is identical, no probing is done.  I'll run a fresh log reproducing this and post it hopefully tomorrow.

[ebr 14897]

Doesn't simply refreshing the item solve it as well...?

[Waldonnis 148]

Doesn't simply refreshing the item solve it as well...?

 

Probably, but I was swapping a lot of files at once and didn't want to refresh the entire library, so I just adapted my script to touch an SRT file while it was moving things into place.  I found it interesting that adding a sub file forced a fresh ffprobe, but doubling the file size didn't