Playback stops for a particular audio track on ATV app only

[Guest]

Hello,

Playback stops at 0m50s for the attached file only when using the ATV app on CCwGTV. The file is not corrupted and plays fine when using the Android app or any other player.

Please let me know if you require more details, logs or whatever.

Thanks!

JM

08 Piano Trio in E-flat Major, op 1, no 1_ IV Finale_ Presto.flac

[Luke 42077]

 

Hi there, let's look at an example. Please attach the information requested in how to report a media playback issue. Thanks!

 

[Guest]

Attached is the server log. I can't find anything unusual but perhaps you'll say otherwise.

The music stops playing at 0m50s only when using the ATV app on both my CCwGTV (HD) when playing this specific song. Haven't had this issue with another audio track so far.

The timer freezes at the said time, music stops but the artwork and song info remain displayed on screen.

The application log has been transmitted as well at approximately 11:03 EST today, userID is mserv.

embyserver.txt

[ebr 16170]

Hi. Is the app responsive and what does the play pause button look like when this happens?

[Guest]

The app responds normally except for both the timer and progression bar being stopped at position 0:50.

The spectrum analyser animation is still in motion and the play button is showing a pause symbol as it would if music was still playing.

I can also navigate through the screens or simply press the skip buttons to play the other songs.

I've re-up'ed the track to the server with its filename changed and meta stripped but to no avail.

I have yet to try transcoding it to other lossless formats to see if it behaves likewise, test VBR vs CBR codecs etc.

I might also take a look at the spectrogram for this specific file in order to verify if there's anything odd at that time position which could trigger a bug.

Quite a head-scratcher, isn't it?

[ebr 16170]

If you look at the now playing card on the server, does it keep advancing about 10 seconds and then going back to the "stuck" point?

[Guest]

The Now Playing card keeps disappearing after barely two seconds most of the time for some reason, no matter what I play.

However, after a while, it remained visible long enough and I confirm that it behaved exactly the way you mentioned.

If you don't mind me asking, have you guys actually tried playing the track on a similar setup to see if it's only something at my end or for anyone using the ATV app?

[ebr 16170]

8 hours ago, trance_planet said:

If you don't mind me asking, have you guys actually tried playing the track on a similar setup to see if it's only something at my end or for anyone using the ATV app?

I have not been able to test it yet.

[Guest]

Ok.

I did some testing and came out with the following results.

When transcoded to other lossless formats, newly generated files are playable with no issue. [good]

When transcoded back to its original format, the new FLAC file is also playable. [yay.]

When the original flac file is bit compared to any of its counterparts, all their decoded content is identical. [yay. maintained]

The only technical difference I noticed between the two FLAC files were the writing libraries used at the time they were created:

          Original defective file — libFLAC 1.3.1 (2014-11-25)
          New working file — libFLAC 1.4.3 (2023-06-23)

 

Although this is inconclusive, rewriting the file using an updated version of the codec seems to be an effective and easy workaround at the moment.

Hope these findings can be helpful in the troubleshooting process.

[Guest]

Just my two cents if I may on another detail since I have your attention and there was a Beethoven song involved...

If a song is classical and identified as such, the composer field should also [always] be displayed upon playback.

I'll refer to this request as common sense [industry standard] and not some "elitist caprice" as it is sometimes perceived. But granted, this genre is a total PITA [read: any if not all of Carlin's 7-dirties, chef's choice] when it comes to metadata management. Big time.

[Luke 42077]

On 3/20/2024 at 11:18 AM, trance_planet said:

Ok.

I did some testing and came out with the following results.

When transcoded to other lossless formats, newly generated files are playable with no issue. [good]

When transcoded back to its original format, the new FLAC file is also playable. [yay.]

When the original flac file is bit compared to any of its counterparts, all their decoded content is identical. [yay. maintained]

The only technical difference I noticed between the two FLAC files were the writing libraries used at the time they were created:

          Original defective file — libFLAC 1.3.1 (2014-11-25)
          New working file — libFLAC 1.4.3 (2023-06-23)

 

Although this is inconclusive, rewriting the file using an updated version of the codec seems to be an effective and easy workaround at the moment.

Hope these findings can be helpful in the troubleshooting process.

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.

 

[Guest]

29 minutes ago, Luke said:

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

I've sideloaded the Android app (arm7) and I do not encounter this issue when playing the audio file on the CCwGTV device.

[Luke 42077]

5 minutes ago, trance_planet said:

I've sideloaded the Android app (arm7) and I do not encounter this issue when playing the audio file on the CCwGTV device.

Great, thanks. Are you happy continuing to use this?

[Guest]

27 minutes ago, Luke said:

Great, thanks. Are you happy continuing to use this?

I cannot provide a definitive answer until I have tested it for a while but it seems alright so far.

With all due respect, is the sideloading alternative an auto-response for anyone dealing with a bug on the ATV app or are there any actual intentions to fix such issues eventually?

I understand this isn't [and shouldn't be] a priority but I'm still asking.

[ebr 16170]

The plan is to eventually move everyone to the other app so, if that solves whatever issue you may have, then we don't want to spend any more time or resources on that issue.  Thanks.

[Guest]

I see.

[Luke 42077]

On 3/25/2024 at 3:41 PM, Guest said:

I cannot provide a definitive answer until I have tested it for a while but it seems alright so far.

With all due respect, is the sideloading alternative an auto-response for anyone dealing with a bug on the ATV app or are there any actual intentions to fix such issues eventually?

I understand this isn't [and shouldn't be] a priority but I'm still asking.

HI, we are working on getting it into the store for TV devices, so that's only a matter of time.