View Issue Details

IDProjectCategoryView StatusLast Update
0019535MediaMonkey 5Casting (Google Cast / UPnP)public2022-11-17 15:49
Reporterrusty Assigned To 
PriorityurgentSeverityminorReproducibilityalways
Status closedResolutionfixed 
Product Version5.0.4 
Target Version5.0.4Fixed in Version5.0.4 
Summary0019535: Chromecast: Some m4a files consistently fail to cast
DescriptionI've found a few m4a files that always fail to cast, even though the play normally in MM.

Could it be that they're corrupted? Or perhaps the auto-conversion rules need tweaking?

Sample uploaded to ftp (agnes obel - familiar).
TagsNo tags attached.
Fixed in build2682

Relationships

related to 0017540 closedLudek Casting: incompatible files are sent to the chromecast without auto-conversion 
related to 0013277 closedLudek Add auto-conversion profile for Chromecast (adjust for ALAC) 
related to 0019494 closedmichal Silent failure of MP4 > WEBM auto-conversion when codec pack isn't installed 

Activities

peke

2022-11-04 00:34

developer   ~0070132

Reminder sent to: michal

Ludek

2022-11-04 11:16

developer   ~0070134

Last edited: 2022-11-04 11:40

Testing the sample file and Chromecast plays it for half a second and then replies with '"detailedErrorCode":104' {MEDIA_SRC_NOT_SUPPORTED}

Based on 0017540 there is a fallback to auto-conversion, but the fallback works only when Chromecast can't play the file at all, in this case it plays for half a second so the fallback isn't used and the file is just skipped.

Ludek

2022-11-04 11:39

developer   ~0070135

Last edited: 2022-11-04 11:50

I have adjusted the fallback (in build 2682) so that file is considered as playing only if it played at least 1 second => which resolves the issue in this case (as file is then auto-converted to MP3 stream and played on CC)

Michal did not find nothing unusual with the file format except for the very high and unusual bitrate (436 kbps) -- while normally you can convert max to 320 kbps.

michal

2022-11-04 11:50

developer   ~0070136

Yes, the bitrate is strange, I am not able to create AAC file with constant bitrate above 320kbps and this file has 436kbps.
Rusty, in case you have more AAC (not ALAC) files with such high bitrates, could you test which bitrate plays without autoconversion and which not? Maybe there is some limit, which is causing the problem, then we can speed things up by adjusting autoconvert rule. To be sure file is autoconverted, clear Portable\Temp\Transcoded_Media_Files and see, if MP3 is created.

rusty

2022-11-05 23:18

administrator   ~0070165

Verified 2682 across various M4A files at various bitrates.

Leaving 'resolved' to test 2681 at various bitrates to determine which specific bitrates are problematic in order to further optimize.

Ludek

2022-11-08 16:19

developer   ~0070207

BTW: I think that the M4A files with higher bitrates might be ALAC (as ALAC isn't supported by Chromecast)
details in 0013277:0049678 where we added the auto-convert rule M4A above 528 kbps > MP3 VBR 192 to workaround this.

michal

2022-11-08 17:32

developer   ~0070211

These were really AAC (CBR).

peke

2022-11-10 12:50

developer   ~0070237

Last edited: 2022-11-10 13:39

Verified 2683

TEST Note: Video apps can encode AAC CBR >320 eg up to 1024 so in testing, I found that I was able to replicate the bug with any aac/m4a track encoded at >400kbps

peke

2022-11-10 12:51

developer   ~0070238

image.png (15,026 bytes)   
image.png (15,026 bytes)   

rusty

2022-11-17 03:05

administrator   ~0070361

I just tested this in build 2686 and it doesn't seem to be working. Was a change made after build 2682 (that's when I last tested this)?

Ludek

2022-11-17 12:20

developer   ~0070363

Last edited: 2022-11-17 12:24

I am not aware of any change related to casting since 2682 with exception to the firewall related issues which shouldn't affect existing installations though.

So in any case I'll need to see debug log.

Ideally if you could generate two logs:
1) Working casting with 2682
2) Non-working casting (on the same testing tracks) with 2686

Ludek

2022-11-17 15:17

developer   ~0070369

Last edited: 2022-11-17 15:27

Rusty indicated that the failure happens in both 2682 & 2686, but he is now testing on brand new PC where the issue occurs, waiting for logs...

EDIT: Logs shown that the file is deadlink on the new machine.

rusty

2022-11-17 15:49

administrator   ~0070371

Yes--my re-opening of this issue was due to a test error. In my haste to discover a reason for the failure described at https://www.mediamonkey.com/forum/viewtopic.php?p=502843#p502843 , I didn't realize that the files I was testing with were inaccessible (migration-related).