ebr 14960 Posted December 26, 2022 Share Posted 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. Link to comment Share on other sites More sharing options...
salvadordalisdad 5 Posted December 30, 2022 Author Share Posted 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 Link to comment Share on other sites More sharing options...
Solution ebr 14960 Posted December 30, 2022 Solution Share Posted 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. Link to comment Share on other sites More sharing options...
salvadordalisdad 5 Posted December 31, 2022 Author Share Posted 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. Link to comment Share on other sites More sharing options...
ebr 14960 Posted January 2, 2023 Share Posted January 2, 2023 You can use the ADB as well. Link to comment Share on other sites More sharing options...
moixonas 1 Posted January 2, 2023 Share Posted January 2, 2023 hello, I had the same problem and when I installed the beta version, it has been corrected. 1 Link to comment Share on other sites More sharing options...
salvadordalisdad 5 Posted January 5, 2023 Author Share Posted 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. 1 Link to comment Share on other sites More sharing options...
Kosmik 0 Posted June 2, 2023 Share Posted 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. Link to comment Share on other sites More sharing options...
Luke 37272 Posted June 14, 2023 Share Posted 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. Link to comment Share on other sites More sharing options...
deadpoolio 0 Posted February 4 Share Posted 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. Link to comment Share on other sites More sharing options...
ebr 14960 Posted February 4 Share Posted 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? Link to comment Share on other sites More sharing options...
deadpoolio 0 Posted February 4 Share Posted 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.) Link to comment Share on other sites More sharing options...
salvadordalisdad 5 Posted February 5 Author Share Posted 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? Link to comment Share on other sites More sharing options...
salvadordalisdad 5 Posted February 5 Author Share Posted 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. 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? EDIT - I just did a fresh search (been a while) & now there's TDARR - when I get a moment I will give it a try, apparently it works for AVI files. So more power to Emby to get the fix into the mainstream code please. Pretty please? Link to comment Share on other sites More sharing options...
deadpoolio 0 Posted February 5 Share Posted February 5 2 hours ago, salvadordalisdad said: Hiya ... EDIT - I just did a fresh search (been a while) & now there's TDARR - when I get a moment I will give it a try, apparently it works for AVI files. Yeah, it appears to be another server application with Handbrake at its core. There is also a link on their github to another application that is a batch processor for handbrake. Those will work to fix the files outside of Emby and then Emby will possibly have to reload the metadata because it isn't emby doing the conversion and maintaining the link to the metadata. Link to comment Share on other sites More sharing options...
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now