|
|
Reminder sent to: michal |
|
|
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. |
|
|
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. |
|
|
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. |
|
|
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. |
|
|
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. |
|
|
These were really AAC (CBR). |
|
|
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 |
|
|
image.png (15,026 bytes) |
|
|
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)? |
|
|
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 |
|
|
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. |
|
|
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). |
- Anonymous
