AVI files - video stops audio continues but file is AOK

December 26, 2022

Thanks for the sample. I can make it progress past that point by transcoding but now I'm wondering what condition we should use to make that decision. The issue is actually in the audio track, not the video. The timestamps in the audio are incorrect and that is causing the player to lose track of where it should be. Exo uses the audio track as the main timing mechanism so, when it loses proper position there, it doesn't know where to go in the video.

December 30, 2022

On 26/12/2022 at 16:05, ebr said:

Thanks for the sample. I can make it progress past that point by transcoding but now I'm wondering what condition we should use to make that decision. The issue is actually in the audio track, not the video. The timestamps in the audio are incorrect and that is causing the player to lose track of where it should be. Exo uses the audio track as the main timing mechanism so, when it loses proper position there, it doesn't know where to go in the video.

Hiya,

Wow that's really interesting, good deduction work.

Yes I too can get past that point with transcoding (well usually, sometimes it fails with '"too many errors" which usually means rebooting the telly to fully reset the Emby client, then start again, select transcoding at the start & then ffwd to the 35 mins point).

I have shown the users (er, my family) and also left instructions on how to do this, but it's not ideal.

It only started quite recently, so I reckon that if I tried a version from, maybe 1 year ago it would still work, then step fwd to all the major versions until it broke - maybe that is a blunt but effective way to find out what changed? Just a thought, happy to be the guinea pig if you like. I've never side-loaded an app before...on reflection, I would probably need to block the TV on the firewall so it didn't auto-update before the test was done, not a problem.

Thanks, seasons greetings.

TTFN

December 30, 2022

2 hours ago, salvadordalisdad said:

It only started quite recently, so I reckon that if I tried a version from, maybe 1 year ago it would still work

We used to always transcode AVI files which is why this is a new problem.

2 hours ago, salvadordalisdad said:

Just a thought, happy to be the guinea pig if you like

The latest beta should work fine.

December 31, 2022

On 30/12/2022 at 14:31, ebr said:

We used to always transcode AVI files which is why this is a new problem.

The latest beta should work fine.

Hiya,

Thanks, very much appreciated. I now have the APK file, any nudges in the right direction of how to load that on the TV?

I've googled it, but all I see is "use this XYZ app to load the apk" and those all look pretty dodgy, so a recommendation would save a lot of risk, thanks.

January 2, 2023

You can use the ADB as well.

January 2, 2023

hello, I had the same problem and when I installed the beta version, it has been corrected.

January 5, 2023

Hi ebr

Thanks, I can confirm that the beta works as you suggested, immediately transcoded AVI, so no glitch, marvellous.

...and what an adventure, I learned a lot loading the beta, nice one!

Will it be overwritten when the new version comes out or do I need to check it manually? (not that I care an awful lot, as it's working, but in the interests of staying approx mainstream...)

Will report back if any oddities, not expecting any.

Thanks enormously for sorting this out. Very much appreicated.

You've made a happy man very old, or something.

June 2, 2023

On 1/2/2023 at 3:16 PM, ebr said:

You can use the ADB as well.

Sorry ADB? I have the same problem but run other servers in parrallel but I see the emby app on Playstore is from Oct 2022?

Using a Mi Stick with Android TV.

June 14, 2023

On 6/2/2023 at 3:26 AM, Kosmik said:

Sorry ADB? I have the same problem but run other servers in parrallel but I see the emby app on Playstore is from Oct 2022?

Using a Mi Stick with Android TV.

Hi. Can you try sideloading our standard android app on the same device and see how that compares?

https://emby.media/emby-for-android.html

Thanks.

February 4

I call this the 35:47 bug. It only applies to .AVI files more specifically files that Emby identifies as 'SD MPEG4'. I even moved over to the beta versions of the server in hopes that things would get better and have started noticing that .AVI files I have watched on previous versions are starting to mess up at 35:47. I have multi device types (computers, phones, tablets, android tv boxes (the generics), google chromecast with android tv, and nvidia shields) all of these are running the 'sideload' version from the website, as that that is always the first answer to any technical issues.

All of this being said, if AVI files are so 'old' then why attempt to maintain compatibility? Why not put something in place that will convert them to mp4, replace the existing file and give the new converted file the exact same name as the original file to help maintain metadata and subtitle connectivity? Or a plug-in that will find the .AVI files and do the same. I have used the converter on some .AVI files that 'bugged out' and the new file worked just fine.

February 4

1 hour ago, deadpoolio said:

Why not put something in place that will convert them to mp4, replace the existing file and give the new converted file the exact same name as the original file to help maintain metadata and subtitle connectivity?

Hi. We have exactly this feature. It is called "Convert". Have you tried that?

February 4

2 minutes ago, ebr said:

Hi. We have exactly this feature. It is called "Convert". Have you tried that?

Like I said in my previous post I have used the converter and it works great. I was pointing to the fact that it isn't automated and is still a one time manual process. Which is great for when you need to convert a 'one off' but not so much when you are working with a collection that began in days of DivX and Xvid when .AVI was the standard and you backed up your DVD collection...lol.

I am not trying to make anyone mad or pick a fight, I have been an Emby user for several years (tried them all and nothing compares overall) and the issues around .AVI files have gotten worse throughout updating the beta builds so utilizing the 'Reports' plugin I have discovered that I have a LOT of .AVI files. I am merely suggesting enhancements and automation to the existing 'Convert' option. (ability to search the library based on media type (ex. Movies or TV Show) and then search based on dropdown list of emby file type labels similar to the 'Reports' plugin and then the ability to check the files you want to covert or select all and then have it run whenever the server isn't in use.)

February 5

15 hours ago, deadpoolio said:

I call this the 35:47 bug. It only applies to .AVI files more specifically files that Emby identifies as 'SD MPEG4'. I even moved over to the beta versions of the server in hopes that things would get better and have started noticing that .AVI files I have watched on previous versions are starting to mess up at 35:47. I have multi device types (computers, phones, tablets, android tv boxes (the generics), google chromecast with android tv, and nvidia shields) all of these are running the 'sideload' version from the website, as that that is always the first answer to any technical issues.

All of this being said, if AVI files are so 'old' then why attempt to maintain compatibility? Why not put something in place that will convert them to mp4, replace the existing file and give the new converted file the exact same name as the original file to help maintain metadata and subtitle connectivity? Or a plug-in that will find the .AVI files and do the same. I have used the converter on some .AVI files that 'bugged out' and the new file worked just fine.

Hiya

Yes Deadpoolio, this is exactly what I found originally.

I used (side loaded) a beta code version of Emby client on my TV, and that worked AOK. NO stoppages.

However, since then it has been updated so the fix is gone now, and it stops at 35:47 again, every time.

Using the workaround "down-click -> settings -> fix playback-> yes" (paraphrased as I can't see the telly from here) does resolve it if you remember this file has the probklem & do it any time before 35:47, as it's broken after that.

I don't know what they did in the beta code which worked, but I wish they'd release it into the mainstream, as it worked a treat.

I too have a few hundred of these affected files, so I don't consider it realistic to have to "convert" all of them individually, either with Emby or some other tool.

Maybe someone should write some sort of UNMANIC which would do like that does for H.264 -> H.265 ?

UNMANIC searches through the chosen storage location, analyses the files, finds the H.264 MKV containers & converts them in-place to H.265, nice.

Maybe a similar tool which finds the AVI files, and converts them to H.265 MKV format? Anyone know of such a tool?

Of course, I have no idea what characteristic of AVI files is the offending bit, so that's kinda academic innit?

So more power to Emby to get the fix into the mainstream code please. Pretty please?

February 5

16 hours ago, deadpoolio said:

I call this the 35:47 bug. It only applies to .AVI files more specifically files that Emby identifies as 'SD MPEG4'. I even moved over to the beta versions of the server in hopes that things would get better and have started noticing that .AVI files I have watched on previous versions are starting to mess up at 35:47. I have multi device types (computers, phones, tablets, android tv boxes (the generics), google chromecast with android tv, and nvidia shields) all of these are running the 'sideload' version from the website, as that that is always the first answer to any technical issues.

All of this being said, if AVI files are so 'old' then why attempt to maintain compatibility? Why not put something in place that will convert them to mp4, replace the existing file and give the new converted file the exact same name as the original file to help maintain metadata and subtitle connectivity? Or a plug-in that will find the .AVI files and do the same. I have used the converter on some .AVI files that 'bugged out' and the new file worked just fine.