Jump to content

Strange glitch in playback via Android app only


Recommended Posts

nospotify
Posted

I imported a new album to my library apparently without problem. Unfortunately Emby playback stops dead with 5 seconds left on the first track, but ONLY in the Android app. To attempt to debug:

  • I renamed, moved, and reimported the entire album into Emby server.
  • I did a disc scan to confirm the files are fine.
  • I am successfully able to play the track and have it complete and move the the next track in the album via Ebmy's Web interface
  • I am successfully able to play the track and have it complete and move the the next track in the album in multiple music apps (VLC, Groove) running on the PC where the server resides.

ONLY in the Android app does the file seize up and stop playing, which isn't happening with other albums. Same issue occurs in the Android app on two very different devices: Samsung tablet, and Pixel phone. Both devices can play the file fine via a web browser, so it seems clear the problem is the Android app. Any idea on how to figure out and resolve this problem?  

nospotify
Posted (edited)

Correct log file now attached.

 

embyserver.txt

Edited by wordlover
wrong file - will edit momentarily.
nospotify
Posted

Reproduced problem again. PM'd Luke the latest log file.

Posted

What type of tracks are you trying to play?

nospotify
Posted (edited)

Standard mp3 music tracks.

Edited by wordlover
Posted

Can you provide a sample track for testing?

nospotify
Posted

Sample tracks sent via PM

Posted

Are you sure these are the right tracks? I'm able to play them using Emby for Android 3.2.32.

nospotify
Posted

They play fine for me, too, but when I play them in an album queue, each stops about 4 or 5 seconds from the end and the app - on two different devices - sizes up until I use back button to leave the player screen.

  • 2 weeks later...
Posted
On 12/17/2021 at 11:57 AM, wordlover said:

They play fine for me, too, but when I play them in an album queue, each stops about 4 or 5 seconds from the end and the app - on two different devices - sizes up until I use back button to leave the player screen.

@wordlover

Can you try sideloading from our website and let us know if it's still an issue: https://emby.media/emby-for-android.html

Thanks.

nospotify
Posted

@Luke Prefer not to do that. I'll just give up on this album.

Posted

OK please try again with the next update to the app and let us know if that helps. Thanks.

  • Thanks 1
nospotify
Posted

@Luke Will do. When is next Android app update likely, and when is next Windows server update likely?

  • 2 weeks later...
nospotify
Posted

@Luke The problem of frozen playback continues with the Android app - this time the same issue with an entirely different track and album: 

Android app on Samsung tablet: problem - play album, first track completely stops with :14 left, and impossible to continue or skip to next track 

Android app on Pixel 5a phone: identical problem

Web interface on Pixel 5a phone and ALL OTHER DEVICES: no problem at all 

It looks like Emby is listing the LENGTH of the track via all clients (android and web) as 21:49, when the length in Mp3tag is 21:35. So. when :14 is left in the track (the difference between these two lengths), the Android client seizes up, and even the app's STOP button does not work, and the only way to end the frozen playback is pressing the device's own BACK button. Again, no problem at all in Web interface on any device. MP3 file and Emby log file attached. This seems related to another thread where a similar issue was reported.

 

embyserver_21220110.txt

Posted
57 minutes ago, wordlover said:

@Luke The problem of frozen playback continues with the Android app - this time the same issue with an entirely different track and album: 

Android app on Samsung tablet: problem - play album, first track completely stops with :14 left, and impossible to continue or skip to next track 

Android app on Pixel 5a phone: identical problem

Web interface on Pixel 5a phone and ALL OTHER DEVICES: no problem at all 

It looks like Emby is listing the LENGTH of the track via all clients (android and web) as 21:49, when the length in Mp3tag is 21:35. So. when :14 is left in the track (the difference between these two lengths), the Android client seizes up, and even the app's STOP button does not work, and the only way to end the frozen playback is pressing the device's own BACK button. Again, no problem at all in Web interface on any device. MP3 file and Emby log file attached. This seems related to another thread where a similar issue was reported.

 

embyserver_21220110.txt 518.95 kB · 0 downloads

If you refresh the metadata on that track, what runtime does it show after that?

Happy2Play
Posted

Interesting, Looking at this file further, but devs may have to comment. @Luke

Spoiler

C:\Users\Media\AppData\Roaming\Emby-Server\system>ffprobe -i "C:\Users\Media\Downloads\147283278_01RagaMedhavi.mp3" -show_streams -show_format -print_format json
ffprobe version 4.5.0-emby_2021_12_10-g463c71b3b3+1170 Copyright (c) 2007-2021 the FFmpeg developers and softworkz for Emby LLC
  built with gcc 10.3.0 (Rev5, Built by MSYS2 project)
{
[mp3 @ 000001edff63d700] Estimating duration from bitrate, this may be inaccurate
Input #0, mp3, from 'C:\Users\Media\Downloads\147283278_01RagaMedhavi.mp3':
  Metadata:
    album           : Three Ragas
    artist          : Ustad Ali Akbar Khan and Pandit Mahapurush Misra
    album_artist    : Ustad Ali Akbar Khan and Pandit Mahapurush Misra
    comment         : Signature Series Vol. II
    composer        : Ustad Ali Akbar Khan and Pandit Mahapurush Misra
    genre           : World, Indian
    title           : Raga Medhavi
    track           : 1
    date            : 1966
    id3v2_priv.XMP  : <?xpacket begin="\xef\xbb\xbf" id="W5M0MpCehiHzreSzNTczkc9d"?>\x0a<x:xmpmeta xmlns:x="adobe:ns:meta/" x:xmptk="3.1.2-113">\x0a <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#">\x0a  <rdf:Description rdf:about=""\x0a    xmlns:xmpDM="http://
  Duration: 00:21:49.71, start: 0.000000, bitrate: 258 kb/s
  Stream #0:0: Audio: mp3, 44100 Hz, stereo, fltp, 256 kb/s
  Stream #0:1: Video: mjpeg (Progressive), yuvj444p(pc, bt470bg/unknown/unknown), 600x591 [SAR 100:100 DAR 200:197], 90k tbr, 90k tbn (attached pic)
    Metadata:
      comment         : Cover (front)
    "streams": [
        {
            "index": 0,
            "codec_name": "mp3",
            "codec_long_name": "MP3 (MPEG audio layer 3)",
            "codec_type": "audio",
            "codec_tag_string": "[0][0][0][0]",
            "codec_tag": "0x0000",
            "sample_fmt": "fltp",
            "sample_rate": "44100",
            "channels": 2,
            "channel_layout": "stereo",
            "bits_per_sample": 0,
            "r_frame_rate": "0/0",
            "avg_frame_rate": "0/0",
            "time_base": "1/14112000",
            "start_pts": 0,
            "start_time": "0.000000",
            "duration_ts": 18482601942,
            "duration": "1309.708187",
            "bit_rate": "256000",
            "disposition": {
                "default": 0,
                "dub": 0,
                "original": 0,
                "comment": 0,
                "lyrics": 0,
                "karaoke": 0,
                "forced": 0,
                "hearing_impaired": 0,
                "visual_impaired": 0,
                "clean_effects": 0,
                "attached_pic": 0,
                "timed_thumbnails": 0,
                "captions": 0,
                "descriptions": 0,
                "metadata": 0,
                "dependent": 0,
                "still_image": 0
            }
        },
        {
            "index": 1,
            "codec_name": "mjpeg",
            "codec_long_name": "Motion JPEG",
            "profile": "Progressive",
            "codec_type": "video",
            "codec_tag_string": "[0][0][0][0]",
            "codec_tag": "0x0000",
            "width": 600,
            "height": 591,
            "coded_width": 600,
            "coded_height": 591,
            "closed_captions": 0,
            "film_grain": 0,
            "has_b_frames": 0,
            "sample_aspect_ratio": "1:1",
            "display_aspect_ratio": "200:197",
            "pix_fmt": "yuvj444p",
            "level": -99,
            "color_range": "pc",
            "color_space": "bt470bg",
            "chroma_location": "center",
            "refs": 1,
            "r_frame_rate": "90000/1",
            "avg_frame_rate": "0/0",
            "time_base": "1/90000",
            "duration_ts": 117873737,
            "duration": "1309.708189",
            "bits_per_raw_sample": "8",
            "disposition": {
                "default": 0,
                "dub": 0,
                "original": 0,
                "comment": 0,
                "lyrics": 0,
                "karaoke": 0,
                "forced": 0,
                "hearing_impaired": 0,
                "visual_impaired": 0,
                "clean_effects": 0,
                "attached_pic": 1,
                "timed_thumbnails": 0,
                "captions": 0,
                "descriptions": 0,
                "metadata": 0,
                "dependent": 0,
                "still_image": 0
            },
            "tags": {
                "comment": "Cover (front)"
            }
        }
    ],
    "format": {
        "filename": "C:\\Users\\Media\\Downloads\\147283278_01RagaMedhavi.mp3",
        "nb_streams": 2,
        "nb_programs": 0,
        "format_name": "mp3",
        "format_long_name": "MP2/3 (MPEG audio layer 2/3)",
        "start_time": "0.000000",
        "duration": "1309.708189",
        "size": "42375924",
        "bit_rate": "258841",
        "probe_score": 51,
        "tags": {
            "album": "Three Ragas",
            "artist": "Ustad Ali Akbar Khan and Pandit Mahapurush Misra",
            "album_artist": "Ustad Ali Akbar Khan and Pandit Mahapurush Misra",
            "comment": "Signature Series Vol. II",
            "composer": "Ustad Ali Akbar Khan and Pandit Mahapurush Misra",
            "genre": "World, Indian",
            "title": "Raga Medhavi",
            "track": "1",
            "date": "1966",
            "id3v2_priv.XMP": "<?xpacket begin=\"\\xef\\xbb\\xbf\" id=\"W5M0MpCehiHzreSzNTczkc9d\"?>\\x0a<x:xmpmeta xmlns:x=\"adobe:ns:meta/\" x:xmptk=\"3.1.2-113\">\\x0a <rdf:RDF xmlns:rdf=\"http://www.w3.org/1999/02/22-rdf-syntax-ns#\">\\x0a  <rdf:Description rdf:about=\"\"\\x0a    xmlns:xmpDM=\"http://ns.adobe.com/xmp/1.0/DynamicMedia/\"\\x0a   xmpDM:genre=\"Other\"\\x0a   xmpDM:audioSampleRate=\"44100\"\\x0a   xmpDM:audioSampleType=\"16-bit\"\\x0a   xmpDM:audioChannelType=\"2\"\\x0a   xmpDM:audioCompressor=\"\"\\x0a   xmpDM:duration=\"21:35.266\"\\x0a   xmpDM:loop=\"False\"\\x0a   xmpDM:numberOfBeats=\"2591\"\\x0a   xmpDM:key=\"C\"\\x0a   xmpDM:tempo=\"120\"\\x0a   xmpDM:stretchMode=\"Fixed Length\"\\x0a   xmpDM:relativeTimestamp=\"\">\\x0a  </rdf:Description>\\x0a </rdf:RDF>\\x0a</x:xmpmeta>\\x0a                                                                                                    \\x0a                                                                                                    \\x0a                                                                                                    \\x0a                                                                                                    \\x0a                                                                                                    \\x0a                                                                                                    \\x0a                                                                                                    \\x0a                                                                                                    \\x0a                                                                                                    \\x0a                                                                                                    \\x0a                                                                                                    \\x0a                                                                                                    \\x0a                                                                                                    \\x0a                                                                                                    \\x0a                                                                                                    \\x0a                                                                                                    \\x0a                                                                                                    \\x0a                   \\x0a<?xpacket end=\"w\"?>"
        }
    }
}

 

nospotify
Posted

No change in length.

Can I suggest that regardless of what's going on, the most straightforward fix would be to update the Android app so that - like the brower interface - when it comes to the end of a file (however long the file self-identifies its own length) it treats that as the end and then moves to the next track in the active queue. (I imagine there are trillions of files with inaccurate length metadata - so just go with whatever the reality is...)

Posted

Yes we can take a look at that. Thanks.

  • Thanks 1
Happy2Play
Posted (edited)
19 hours ago, wordlover said:

(I imagine there are trillions of files with inaccurate length metadata - so just go with whatever the reality is...)

True but all players will not treat them the same.

But MP3 Diags show the defects in the file and can correct them.

image.thumb.png.b3d4c1609421788a68a03e21f3381eba.png

Edited by Happy2Play
nospotify
Posted

True, but given that Emby's browser player handles imperfect files like this (and I am not the only Emby user who has a few imperfect MP3 files), I expect it's a modest code edit to have the Android app (and your others) do the same. 

Happy2Play
Posted

They might be able to but files with bad header information should be fixed, not worked around.

The same issue happens with video files also that requires the users to remux in say mkvtoolnix to correct header defects.

Posted

Our developer who works on the player spends so much time adding workarounds for messy files that it pulls him away from new feature development.

nospotify
Posted

Fair point, indeed, but an issue like this was so obscure neither you nor I figured it out for a while, even when both of us had the original mp3 to examine. Emby's Web player handles the issue, as does VLC and every other player I have tried. The only exception I have found is Emby's Android app. Also, fixing it is proving to be a major technical challenge. MP3Tag can't do it, and MP2Diags is a VERY technically complicated program. FWIW...

Happy2Play
Posted (edited)
14 minutes ago, wordlover said:

Fair point, indeed, but an issue like this was so obscure neither you nor I figured it out for a while, even when both of us had the original mp3 to examine. Emby's Web player handles the issue, as does VLC and every other player I have tried. The only exception I have found is Emby's Android app. Also, fixing it is proving to be a major technical challenge. MP3Tag can't do it, and MP2Diags is a VERY technically complicated program. FWIW...

In the end I believe there is bad header data and has to be remuxed but don't necccarily know of a good process for that.  But know that is basically what MP3 Diags did in the option I chose.

image.png.654e9320b909e40e8842493cd6915928.png

It corrected the 14 second difference, and now has less than a second difference.

Duration: 00:21:35.31

xmpDM:duration=\"21:35.266\"

vs

 Duration: 00:21:49.71

xmpDM:duration=\"21:35.266\"

Edited by Happy2Play
  • Like 1

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 account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...