Closed reacocard closed 5 months ago
Confirmed for both libVLC and Exoplayer, direct playing and transcoding.
Both the item ID (logged in fulldetailactivity and playbackcontroller) and the video URL (logged in videomanager) passed to the players match the ID of the chosen version. Considering those values are correct, it's unclear why the chosen version isn't played.
Tested with 10.8-alpha5 I checked the item/version IDs against the web player, which works as expected.
If this matters at all, when I use the web client to cast to my Google TV, I can successfully get the correct version to play, but I suppose this is circumventing the Android client altogether.
Can confirm this issue is occurring for me to. I select the 1080p version of a file and it will play the 2160p format. It seems like it’s always trying to play the highest quality version available over the option selected.
I had the opposite problem: it was playing 1080p, when I had selected 4k. I don't think it has anything to do with the quality.
Hmmm, I'd have to play around with it to see.
Here's what I've discovered. This issue particularly occurs if the version order is different or inverted on the Android TV app compared to how it's ordered on the regular web interface or computer app. You can alphabetize things purposely so that a lower resolution version is listed as the first (or default) option, however the Android TV app ignores all this and will invert the selection so that the higher resolution is always first/default. This in turn causes the Android TV app to playback the higher resolution version regardless of which version you select from the dropdown menu. If you instead alphabetize things so that the highest resolution version is first/default on web/native app, then the Android TV app's ordering of these will not be inverted, since it will match both alphabetically and descending-resolution-wise, and version selection + playback on Android TV will occur normally and you'll be able to play both versions upon selection.
Apologies for the crude explanation, this is a difficult thing to articulate. The solution to this issue would be for the Android TV app to prioritize the same naming conventions and alphabetical orderings that the web and native apps do, instead of behaving at odds with that and trying to force higher resolution.
If for instance I take a 720p version and a 480p version and mislabel them so that the 720p version is filenamed as "Movie Title (Year Date) - 480p.mp4" and the 480p version is filenamed "Movie Title (Year Date) - 720p.mp4" ... the web and native apps will order these versions according to those filenames, despite what's in the actual video metadata. But on the Android TV app, it evidently ignores these filenames and conventions and instead reads the resolution found in the video metadata itself, and prioritizes that instead, which causes the order to invert, and thus causes the aforementioned ignored selection playback issue. The same issue occurs if you were to name the 480p version as "Movie Title (Year Date) - Default.mp4" and the 720p version as "Movie Title (Year Date) - Non-Default.mp4". The Android TV app will ignore the alphabetical rules that the web and native apps obey, and you will end up with an inverted selection where "Non-Default" is listed ahead of "Default". And again... you will encounter the ignored selection playback issue when trying to play the 480p version. Either selection the user makes will result in only the 720p version being played back.
Simply put, the Android TV app needs to prioritize the version filenames (the stated resolution or the alphabetical order.. or both if a combination of the two is present) in exactly the same way that the web and native apps do. Otherwise this issue will keep on occurring.
Are you saying that if the files were named in such a way that when sorted alphabetically they would be in the same order that they would be in when the Android tv app sorts them then this problem would not exist?
Are you saying that if the files were named in such a way that when sorted alphabetically they would be in the same order that they would be in when the Android tv app sorts them then this problem would not exist?
For certain scenarios like the ones I described above, yeah, that's what it takes to have them be playable using the version selector in the Android TV app as of now. If I recall correctly, you had a scenario where "Extended Edition 2160p" and "Extended Edition 1080p" appeared in that order on the Android TV app, and resulted in only being able to playback the 1080p version. Do you have a screenshot of the version selector dropdown menu for the same movie item in the web interface? Is "Extended Edition 1080p" the first/default version in that?
I was unable to get the correct behavior by following the suggestion to rename the files to be in the same order in both web app and the android tv app.
For example, I have 2 versions of a film on my Jellyfin server which I renamed to get a consistent order:
Film Title - 1080p.mp4
Film Title - 3D.HSBS.mp4
They appear in this order on both the web app and the android tv app. However, when I select the 3D version of the file in the Android TV app, it plays the 2D file instead.
One point of interest which nobody has mentioned yet is that the displayed runtime of the film matches the file selected by the user. In my case, the 2 files have slightly different total runtimes. The progress bar always seems to show the total runtime which matches the file I selected, even though the actual video output does not match. At first, this led me to believe that the 3D version was being cropped and resized to show in 2D. However, I confirmed that it is playing the wrong file based on visual differences between the 2 versions (the 3D version says "the Special 3D Edition of" during the intro)
My current workaround is to use the Jellyfin app on my phone to cast the film to my nvidia shield, which bypasses the Android TV client altogether.
I think I figured out the cause of this bug by accident.
I was attempting to play a movie that I have only a 4K version of and I found it was getting transcoded even though it could direct play. I changed the max streaming bitrate
setting in the playback menu from Auto
to 120mbit/s
and it successfully direct played.
On a hunch I tried playing a movie of which I have a 1080p version and a 4K version. Now that I have changed the max streaming bit rate setting, it plays whatever one I select. I guess it was always playing the lower bitrate version for me because of that setting.
It seems as though the real culprit is the Auto
option in the max streaming bit rate setting. Let me know if changing this setting works for you!
I logged the issue with the max streaming bitrate
behaviour in its own bug:
https://github.com/jellyfin/jellyfin-androidtv/issues/2601
The version selector still inverts the ordering. Bitrates and transcode settings play no role in that whatsoever in my experience. I've proven this in tests using versions of identical or near identical bitrates under the 2000kbps range. If you wanted, for instance, to have a 480p version be the default/top listed version over a 720p version, the AndroidTV will simply not allow you to do it. Both video files could have exactly identical and/or low bitrates and it still wouldn't matter. The app is evidently coded to top list the higher resolution version no matter what.
I stumbled upon a new discovery recently. It's not simply the video resolution that determines the sort order, it's the resolution pixel width (as found in the video's mediainfo).
Take for example:
Let's say the fullscreen version has a resolution of 576p and the widescreen version is 404p.
First of all, you'd expect the app to order these movie items alphabetically, but failing that, you'd expect the 576p (fullscreen) version to be listed first. However, if the pixel width of the 404p (widescreen) version is greater than the pixel width of the 576p (fullscreen) version, then the 404p (widescreen) version will be listed first. When this occurs, of course, only the 404p version will playback regardless of which version the user selects. The only workaround would be to relabel your movie items to be something like this:
With this you lose the ability to decide which version you'd prefer to be the default top-listed version, but at least you gain back the ability to be able to playback both items upon selection.
@nielsvanvelzen Has there been any forward progress on fixing or addressing this issue?
@nielsvanvelzen Has there been any forward progress on fixing or addressing this issue?
No, if there was you would see an update in this issue. I'm not working on the old playback code anymore except for small changes like crash fixes or dependency updates.
@nielsvanvelzen Has there been any forward progress on fixing or addressing this issue?
No, if there was you would see an update in this issue. I'm not working on the old playback code anymore except for small changes like crash fixes or dependency updates.
That's disappointing to hear. I'll reach out to other team members I suppose. A properly functioning version selector seems important.
There are no other team members, I'm the only one maintaining the app and have to prioritize the stuff I work on. If someone wants to try to fix this issue they can open a pull request and I will review it.
@nielsvanvelzen Where in the code might I find the rules by which multi-version movies are ordered?
Edit: I've just now noticed you've stated that
The app relies on the server to send the versions in the correct order. There is no client-side sorting done. If the order is not correct that's an issue on the server, not the client.
in #2744
I will seek solutions from the server side.
I believe there's also the issue that even when you selected a version to player code will sometimes choose a different one. That one would be client side.
@nielsvanvelzen Correct. And that would be the "old playback code", yeah? I believe if the correct order issue can be fixed, then the playback issue will cease being triggered in the first place, in most cases.
And that would be the "old playback code", yeah?
Yes
I believe if the correct order issue can be fixed, then the playback issue will cease being triggered in the first place, in most cases.
From what I remember (I looked into the issue some time ago) this won't be the case. I believe there is a bit of logic somewhere in the old playback code that tries to pick a "best version" when playing an item which will sometimes override the version picked from the details screen.
Well it certainly works in my use case. Whenever I've experienced this issue I creatively rename my files so that the alphabetical ordering conveniently matches with the AndroidTV client's ordering, and all versions become instantly playable again.
Well it certainly works in my use case. Whenever I've experienced this issue I creatively rename my files so that the alphabetical ordering conveniently matches with the AndroidTV client's ordering, and all versions become instantly playable again.
I've been attempting this morning to apply this to a bunch of files, but without luck: even naming them something like "A - Live in Chicago.mkv" and "B - Live in London.mkv" doesn't result in the files showing in alphabetical order in the Android TV app's version picker.
https://github.com/jellyfin/jellyfin/pull/10339 I think has introduced new bugs related to this issue, again.
can confirm I am also experiencing this, especially on TV series. version jellyfin-androidtv 0.16.11 release
this does however seem to not be an issue with a build run against the master
branch af366b90af06c8510df560e263228a30da59431e and release-0.16.z pushed to device via USB debugging. perhaps there was something erronious in the build/deploy/update as I can't reproduce it via android studio and the same device using jellyfin-debug, but when using the official package on the device the issue exists.
I have managed to correct the issue on my device via what I would potentially call a workaround, on my device by clearing the data (Settings -> Apps -> Jellyfin -> Clear Data) for the Jellyfin app and re-authenticating with my server the problem was resolved during next play. I know this doesn't solve the root cause, but could probably assist anyone else with the issue.
This issue still persists unless I manually select 120mbps max bitrate. Server version 10.9.7. AndroidTV version 0.16.11.
Describe the bug
this happens with both multi-format movies i have at the moment
Selecting a version in the web player does work correctly, but attempting to cast from the web player to the androidtv app produces the same problem as selecting it through the app.
Logs
too long for github, attached instead logcat.txt
FFmpeg logs
Media info of the file
Application version
v0.13.0-beta.5
Device information
Nvidia Shield TV Pro 2019
Android version
9.0.1(33.1.0.283)
Jellyfin server version
10.7.7