Is there a way for the addon to differentiate between files with Atmos content and regular EAC3/True HD files?
I ask because Denon AVRs appear incapable of using Atmos on Dolby content if Auro3D has been selected for Dolby content without Atmos.
Say... I want Auro3D (a nice upmixer) to work on DD, DD+ and Dolby TrueHD content. But I don't want to use it for DD+ and TrueHD Atmos. If I set Auro3D to be used for DD content... it's Auro3D for everything Dolby. I can solve this by decoding DD to PCM. But I don't want to do it for DD+ or TrueHD, because that would mean losing Atmos anyway.
Since I have not much faith in Denon recognizing their mistake, I wonder if the addon could help.
Theoretically MediaInfo is more than capable to identify files with Atmos content, as opposed to regular DD, DD+ or TrueHD. So Codec Detection could be maybe setup to differentiate?
I hope so. :-)
Thanks for developing this.
(2023-06-09, 18:49)ashlar Wrote: [ -> ]Is there a way for the addon to differentiate between files with Atmos content and regular EAC3/True HD files?
Unfortunately, no. Atmos isn't its own codec. It can be embedded in either TrueHD or Dolby Digital Plus, and Kodi doesn't report anything more than the codec as part of the data it provides of the video/audio stream.
(2023-06-10, 02:43)pkscout Wrote: [ -> ] (2023-06-09, 18:49)ashlar Wrote: [ -> ]Is there a way for the addon to differentiate between files with Atmos content and regular EAC3/True HD files?
Unfortunately, no. Atmos isn't its own codec. It can be embedded in either TrueHD or Dolby Digital Plus, and Kodi doesn't report anything more than the codec as part of the data it provides of the video/audio stream.
I forgot that Kodi still isn't using Mediainfo...
Atmos absolutely can be detected, see this collage of two different files' audio properties taken from Mediainfo:
Clearly the choice of using Mediainfo is beyond the scope of this plugin so... as a last resort... basing profiles on file name?
Edit: although... I don't get it. Isn't Kodi using ffmpeg to probe files for metadata info when adding to its databases?
a simple ffmpeg -i file.mkv on the first file from the screen above gives this result for audio:
Stream #0:1(eng): Audio: eac3 (Dolby Digital Plus + Dolby Atmos), 48000 Hz, 5.1(side), fltp, 768 kb/s (default)
Same thing for TrueHD with Atmos:
Stream #0:1(eng): Audio: truehd (Dolby TrueHD + Dolby Atmos), 48000 Hz, 7.1, s32 (24 bit)
So it seems that Kodi should be able to differentiate. Why it doesn't?
(2023-06-10, 03:52)ashlar Wrote: [ -> ]So it seems that Kodi should be able to differentiate. Why it doesn't?
Audio Profiles uses a JSONRPC call to Kodi to get the audio stream details. The specific call is
Player.GetProperties, and the specific thing Audio Profiles asks for is the current audio stream, which returns a
Player.Audio.Stream object. In that object is a string for codec which returns one of the follow values from what I can tell:
'dtshd', 'truehd', 'ac3', 'eac3', 'dts', 'dca'
If you want Atmos returned as a valid value, you need to submit an issue to the Github repo at:
https://github.com/xbmc/xbmc
If the issue is worked and Atmos is added, then I can update the addon to differentiate Atmos.
(2023-06-10, 07:45)pkscout Wrote: [ -> ] (2023-06-10, 03:52)ashlar Wrote: [ -> ]So it seems that Kodi should be able to differentiate. Why it doesn't?
Audio Profiles uses a JSONRPC call to Kodi to get the audio stream details. The specific call is Player.GetProperties, and the specific thing Audio Profiles asks for is the current audio stream, which returns a Player.Audio.Stream object. In that object is a string for codec which returns one of the follow values from what I can tell:
'dtshd', 'truehd', 'ac3', 'eac3', 'dts', 'dca'
If you want Atmos returned as a valid value, you need to submit an issue to the Github repo at:
https://github.com/xbmc/xbmc
If the issue is worked and Atmos is added, then I can update the addon to differentiate Atmos.
Since you're a Kodi team member I ask you for confirmation about this.
I have investigated a little but I wish to stress I'm no coder, I'm no dev.
What I found is that there have been three recent commits to ffmpeg, about three weeks after 6.0 final release:
TrueHD -
https://git.ffmpeg.org/gitweb/ffmpeg.git...91450c4e60
DD+ -
https://git.ffmpeg.org/gitweb/ffmpeg.git...575e5c32f2
DTS:X -
https://git.ffmpeg.org/gitweb/ffmpeg.git...ab39b5214e
With these, ffmpeg and ffprobe can provide the info I posted in my previous post.
Now, reading
Omega Alpha's release notes, I notice the following:
Use upstream FFmpeg. This is a big achievement and allows easier FFmpeg updates in the future.
So I wonder, would an issue opened on Kodi's GitHub be meaningful or would it be shot down with the usual "we need to wait ffmpeg to implement this". I don't mean it in an ironic or sarcastic way, it's just that I know that things have always worked that way and I don't know if the recent Omega "using upstream FFmpeg" thing has changed that.
PS
And of course ffmpeg had to cut 6.0 a few days before they implemented this. But that is par for the course, Murphy at his finest, etc.
PPS
It should go without saying (but I'm pedantic and I'll add it anyway) that implementing the above would allow for Kodi to provide a surefire way to display Atmos and DTS:X labels in skins, without relying on file naming.
(2023-06-10, 12:49)ashlar Wrote: [ -> ]Since you're a Kodi team member I ask you for confirmation about this.
I have investigated a little but I wish to stress I'm no coder, I'm no dev.
What I found is that there have been three recent commits to ffmpeg, about three weeks after 6.0 final release:
Kodi is not yet on newer versions of ffmpeg. This will, in fact, have to wait until that is done. There is no firm ETA on that.
(2023-06-10, 13:30)pkscout Wrote: [ -> ]Kodi is not yet on newer versions of ffmpeg. This will, in fact, have to wait until that is done. There is no firm ETA on that.
?
I'm not sure I follow. I am referring to this:
https://kodi.tv/article/kodi-omega-alpha-1/
Now, granted, ffmpeg 6.0 does *not* include those three commits. They were merged after 6.0 went final. But they were very close, so hopefully importing them to the version of ffmpeg 6 that Kodi is using would not be too hard? As I said, I'm no developer, so I want to stress that "hopefully", as I honestly don't know.
That feature (correct labeling of object-based surround codecs) has been asked many times in the past.
I will open a
feature request on the relevant forum. On github it would make no sense... it's not a bug.
(2023-06-10, 18:21)ashlar Wrote: [ -> ] (2023-06-10, 13:30)pkscout Wrote: [ -> ]Kodi is not yet on newer versions of ffmpeg. This will, in fact, have to wait until that is done. There is no firm ETA on that.
?
I'm not sure I follow. I am referring to this: https://kodi.tv/article/kodi-omega-alpha-1/
That is referring to a VERY early build of the NEXT version of Kodi. The current version of Kodi does not use that and does not provide the information you want. Omega will likely not ship until the end of this year at the earliest, and assuming that all the needed JSONRPC changes are made as well, then Audio Profiles could be updated to differentiate Atmos. So check back next year.
Created the account just to say thank you all!
I migrated from windows to ubuntu (Im a total noob), and this add-on was just what I needed.
Currently switching stereo (pulseaudio) and passthrough (alsa) just with 1 shortcut and 2 bash scripts, which I barely have an idea of what they do, I was about to give up but then I found this work of yours pkscout <3 <3
Hello,
Firstly I want to thank you for your great works, the add-on is so much useful in my scenario (AVR with Pre-out + Stereo amp, so I have to change between 3 profiles with different outputs). I'm modifying your codes to treat the DSD music (using a different output compared with another lossless extension in my case) and multi-channel music. It works for me, but I have a weird problem. Yesterday, when I was playing the DSD music songs (with .dsf or .dff extension), the method "onNotification" returned good information about the song so it entered the "auto_music" scenario without problem, but today (after some setting modifications I guess), it returned unknown type as below:
2023-08-23 00:59:46.208 T:3650 debug <general>: CPlayerCoreFactory::GetPlayers(smb://192.168.1.252/homes/hakki/Lossless/DSD/01 - David Elias - The Window - Vision of Her (DSD64).dsf)
2023-08-23 00:59:46.208 T:3650 debug <general>: CPlayerSelectionRule::GetPlayers: considering rule: system rules
2023-08-23 00:59:46.208 T:3650 debug <general>: CPlayerSelectionRule::GetPlayers: matches rule: system rules
2023-08-23 00:59:46.208 T:3650 debug <general>: CPlayerSelectionRule::GetPlayers: considering rule: mms/udp
2023-08-23 00:59:46.208 T:3650 debug <general>: CPlayerSelectionRule::GetPlayers: considering rule: lastfm/shout
2023-08-23 00:59:46.208 T:3650 debug <general>: CPlayerSelectionRule::GetPlayers: considering rule: rtmp
2023-08-23 00:59:46.208 T:3650 debug <general>: CPlayerSelectionRule::GetPlayers: considering rule: rtsp
2023-08-23 00:59:46.208 T:3650 debug <general>: CPlayerSelectionRule::GetPlayers: considering rule: streams
2023-08-23 00:59:46.208 T:3650 debug <general>: CPlayerSelectionRule::GetPlayers: considering rule: dvd
2023-08-23 00:59:46.208 T:3650 debug <general>: CPlayerSelectionRule::GetPlayers: considering rule: discimage
2023-08-23 00:59:46.209 T:3650 debug <general>: CAddonDatabase: SELECT repo.id FROM repo .. took 0 ms
2023-08-23 00:59:46.216 T:3650 debug <general>: CAddonDatabase: query SELECT addons.*, repo.addonID AS repoID FROM addons JOIN addonlinkrepo ON addons.id=addonlinkrepo.idAddon JOIN repo ON repo.id=addonlinkrepo.idRepo WHERE addonlinkrepo.idRepo IN (1) ORDER BY repo.addonID, addons.addonID returned 748 rows in 7 ms
2023-08-23 00:59:46.259 T:3650 debug <general>: CAddonDatabase::GetAddons took 50 ms
2023-08-23 00:59:46.261 T:3650 debug <general>: ADDONS: repository.xbmc.org - 748 addon(s) loaded
2023-08-23 00:59:46.268 T:3650 debug <general>: CPlayerSelectionRule::GetPlayers: considering rule: sdp/asf
2023-08-23 00:59:46.268 T:3650 debug <general>: CPlayerSelectionRule::GetPlayers: considering rule: nsv
2023-08-23 00:59:46.268 T:3650 debug <general>: CPlayerSelectionRule::GetPlayers: considering rule: radio
2023-08-23 00:59:46.268 T:3650 debug <general>: CPlayerCoreFactory::GetPlayers: matched 0 rules with players
2023-08-23 00:59:46.268 T:3650 debug <general>: CPlayerCoreFactory::GetPlayers: adding audiodefaultplayer (PAPlayer)
2023-08-23 00:59:46.268 T:3650 debug <general>: CPlayerCoreFactory::GetPlayers: for video=false, audio=true
2023-08-23 00:59:46.268 T:3650 debug <general>: CPlayerCoreFactory::GetPlayers: for video=true, audio=true
2023-08-23 00:59:46.268 T:3650 debug <general>: CPlayerCoreFactory::GetPlayers: adding player: VideoPlayer
2023-08-23 00:59:46.268 T:3650 debug <general>: CAddonDatabase: SELECT repo.id FROM repo .. took 0 ms
2023-08-23 00:59:46.273 T:3650 debug <general>: CAddonDatabase: query SELECT addons.*, repo.addonID AS repoID FROM addons JOIN addonlinkrepo ON addons.id=addonlinkrepo.idAddon JOIN repo ON repo.id=addonlinkrepo.idRepo WHERE addonlinkrepo.idRepo IN (1) ORDER BY repo.addonID, addons.addonID returned 748 rows in 4 ms
2023-08-23 00:59:46.313 T:3650 debug <general>: CAddonDatabase::GetAddons took 44 ms
2023-08-23 00:59:46.315 T:3650 debug <general>: ADDONS: repository.xbmc.org - 748 addon(s) loaded
2023-08-23 00:59:46.322 T:3650 debug <general>: CPlayerCoreFactory::GetPlayers: added 2 players
2023-08-23 00:59:46.323 T:3775 debug <general>: Thread JobWorker start, auto delete: true
2023-08-23 00:59:46.323 T:3776 debug <general>: Thread PAPlayer start, auto delete: false
2023-08-23 00:59:46.323 T:3775 debug <general>: CFileCache::Open - <smb://192.168.1.252/homes/hakki/Lossless/DSD/01 - David Elias - The Window - Vision of Her (DSD64).dsf> opening
2023-08-23 00:59:46.323 T:3650 debug <general>: OnPlayBackStarted: CApplication::OnPlayBackStarted
2023-08-23 00:59:46.323 T:3776 debug <general>: PAPlayer:rocess - Playback started
2023-08-23 00:59:46.324 T:3650 debug <general>: CAddonDatabase: SELECT repo.id FROM repo .. took 0 ms
2023-08-23 00:59:46.324 T:3775 debug <general>: CSMBFile::Open - opened smb://USERNAME[email protected]/homes/hakki/Lossless/DSD/01 - David Elias - The Window - Vision of Her (DSD64).dsf, fd=10000
2023-08-23 00:59:46.326 T:3775 debug <general>: CFileCache::Open - <smb://192.168.1.252/homes/hakki/Lossless/DSD/01 - David Elias - The Window - Vision of Her (DSD64).dsf> source chunk size is 65536, setting cache chunk size to 65536
2023-08-23 00:59:46.326 T:3775 debug <general>: CFileCache::Open - <smb://192.168.1.252/homes/hakki/Lossless/DSD/01 - David Elias - The Window - Vision of Her (DSD64).dsf> using single memory cache sized 20971520 bytes
2023-08-23 00:59:46.328 T:3777 debug <general>: Thread FileCache start, auto delete: false
2023-08-23 00:59:46.329 T:3775 debug <general>: Open - probing detected format [dsf]
2023-08-23 00:59:46.329 T:3777 debug <general>: CFileCache:rocess - <smb://192.168.1.252/homes/hakki/Lossless/DSD/01 - David Elias - The Window - Vision of Her (DSD64).dsf> cache completely reset for seek to position 216629498
2023-08-23 00:59:46.329 T:3775 debug <general>: CFileCache::Seek - <smb://192.168.1.252/homes/hakki/Lossless/DSD/01 - David Elias - The Window - Vision of Her (DSD64).dsf> waiting for position 216694876
2023-08-23 00:59:46.329 T:3777 debug <general>: CFileCache:rocess - <smb://192.168.1.252/homes/hakki/Lossless/DSD/01 - David Elias - The Window - Vision of Her (DSD64).dsf> source read hit eof
2023-08-23 00:59:46.330 T:3650 debug <general>: CAddonDatabase: query SELECT addons.*, repo.addonID AS repoID FROM addons JOIN addonlinkrepo ON addons.id=addonlinkrepo.idAddon JOIN repo ON repo.id=addonlinkrepo.idRepo WHERE addonlinkrepo.idRepo IN (1) ORDER BY repo.addonID, addons.addonID returned 748 rows in 6 ms
2023-08-23 00:59:46.370 T:3650 debug <general>: CAddonDatabase::GetAddons took 45 ms
2023-08-23 00:59:46.372 T:3650 debug <general>: ADDONS: repository.xbmc.org - 748 addon(s) loaded
2023-08-23 00:59:46.379 T:3777 debug <general>: CFileCache:rocess - <smb://192.168.1.252/homes/hakki/Lossless/DSD/01 - David Elias - The Window - Vision of Her (DSD64).dsf> cache completely reset for seek to position 28
2023-08-23 00:59:46.380 T:3775 debug <general>: Open - avformat_find_stream_info starting
2023-08-23 00:59:46.380 T:3775 debug <general>: ffmpeg[0x55cc9111dfb0]: [dsf] Estimating duration from bitrate, this may be inaccurate
2023-08-23 00:59:46.380 T:3775 debug <general>: Open - av_find_stream_info finished
2023-08-23 00:59:46.380 T:3775 debug <general>: CDVDDemuxFFmpeg::AddStream ID: 0
2023-08-23 00:59:46.380 T:3775 info <general>: CDVDAudioCodecFFmpeg::Open() Successful opened audio decoder dsd_lsbf_planar
2023-08-23 00:59:46.381 T:3775 debug <general>: CSMBFile::Open - opened smb://USERNAME[email protected]/homes/hakki/Lossless/DSD/01 - David Elias - The Window - Vision of Her (DSD64).dsf, fd=10001
2023-08-23 00:59:46.382 T:3650 debug <general>: CMusicGUIInfo::InitCurrentItem(smb://192.168.1.252/homes/hakki/Lossless/DSD/01 - David Elias - The Window - Vision of Her (DSD64).dsf)
2023-08-23 00:59:46.383 T:3775 debug <general>: CSMBFile::Close closing fd 10001
2023-08-23 00:59:46.383 T:3775 debug <general>: file smb://192.168.1.252/homes/hakki/Lossless/DSD/01 - David Elias - The Window - Vision of Her (DSD64).dsf could not be opened for tag reading
2023-08-23 00:59:46.383 T:3775 info <general>: CDVDAudioCodecFFmpeg::GetChannelMap - FFmpeg reported 2 channels, but the layout contains 0 - trying hints
2023-08-23 00:59:46.383 T:3775 debug <general>: SeekTime - seek ended up on time 0
2023-08-23 00:59:46.383 T:3650 info <general>: Skipped 1 duplicate messages..
2023-08-23 00:59:46.383 T:3650 debug <general>: LoadMusicTag: loading tag information for file: smb://192.168.1.252/homes/hakki/Lossless/DSD/01 - David Elias - The Window - Vision of Her (DSD64).dsf
2023-08-23 00:59:46.384 T:3650 debug <general>: CSMBFile::Open - opened smb://USERNAME[email protected]/homes/hakki/Lossless/DSD/01 - David Elias - The Window - Vision of Her (DSD64).dsf, fd=10001
2023-08-23 00:59:46.386 T:3650 debug <general>: ffmpeg[0x0]: Invalid return value 0 for stream protocol
2023-08-23 00:59:46.387 T:3650 info <general>: Skipped 1 duplicate messages..
2023-08-23 00:59:46.387 T:3650 debug <general>: CSMBFile::Close closing fd 10001
2023-08-23 00:59:46.403 T:3650 debug <general>: Loading additional tag info for file smb://192.168.1.252/homes/hakki/Lossless/DSD/01 - David Elias - The Window - Vision of Her (DSD64).dsf
2023-08-23 00:59:46.404 T:3650 debug <general>: CSMBFile::Open - opened smb://USERNAME[email protected]/homes/hakki/Lossless/DSD/01 - David Elias - The Window - Vision of Her (DSD64).dsf, fd=10001
2023-08-23 00:59:46.406 T:3650 debug <general>: ffmpeg[0x0]: Invalid return value 0 for stream protocol
2023-08-23 00:59:46.407 T:3650 info <general>: Skipped 1 duplicate messages..
2023-08-23 00:59:46.407 T:3650 debug <general>: CSMBFile::Close closing fd 10001
2023-08-23 00:59:46.407 T:3650 debug <general>: CPlayerGUIInfo::InitCurrentItem(smb://192.168.1.252/homes/hakki/Lossless/DSD/01 - David Elias - The Window - Vision of Her (DSD64).dsf)
2023-08-23 00:59:46.483 T:3745 debug <general>: [Audio Profiles Service] MONITOR METHOD: Player.OnPlay DATA: {'item': {'type': 'unknown'}, 'player': {'playerid': 0, 'speed': 1}}
2023-08-23 00:59:46.483 T:3745 debug <general>: [Audio Profiles Service] the type is: unknown
2023-08-23 00:59:46.484 T:3745 debug <general>: [Audio Profiles Service] the playing file is: smb://192.168.1.252/homes/hakki/Lossless/DSD/01 - David Elias - The Window - Vision of Her (DSD64).dsf
2023-08-23 00:59:46.484 T:3745 debug <general>: [Audio Profiles Service] got auto_unknown from the content auto switch
2023-08-23 00:59:46.484 T:3745 debug <general>: [Audio Profiles Service] got a content autoswitch of auto_unknown
So now I have to treat it as "auto_unknown" type by duplicating the code in "auto_music". I'm pretty sure that this file was detected as a song yesterday, like all of my DSD files. Do you have any ideas why the method "onNotification" returning type "unknown" now
In the logs, it seems that the player can open the file with appropriated audio decoder at this line
2023-08-23 00:59:46.380 T:3775 info <general>: CDVDAudioCodecFFmpeg::Open() Successful opened audio decoder dsd_lsbf_planar
Thanks in advance for your help and I hope that I could contribute to your development.
We prefer that you upload unredacted logs with debug-level logging enabled to paste.kodi.tv -- makes life easier for everyone.
scott s.
.
(2023-08-23, 08:17)hakkinenvthh Wrote: [ -> ]Sorry, I'm new here, I reposted the logs in the below link (I can't edit my first post)
https://paste.kodi.tv/uceraxices.kodi
Many thanks for your help!
Kodi core returned unknown as the type, so that's what we have to work with on the addon side. I can't say why core did that, especially with only a log snippet. We really need a full and complete log, not just the snippet. Put Kodi in debug mode, restart Kodi, duplicate the issue, and then put the entire log in pastebin. Maybe that'll show something that will tell us why core is doing that.
(2023-08-23, 11:38)pkscout Wrote: [ -> ] (2023-08-23, 08:17)hakkinenvthh Wrote: [ -> ]Sorry, I'm new here, I reposted the logs in the below link (I can't edit my first post)
https://paste.kodi.tv/uceraxices.kodi
Many thanks for your help!
Kodi core returned unknown as the type, so that's what we have to work with on the addon side. I can't say why core did that, especially with only a log snippet. We really need a full and complete log, not just the snippet. Put Kodi in debug mode, restart Kodi, duplicate the issue, and then put the entire log in pastebin. Maybe that'll show something that will tell us why core is doing that.
Yeah you are right, no problem when we can treat it on the add-on side. I notice that when I call the method "GetProperties" on the player to get the current stream 's informations with some *.dsf or *.dff files, it takes time so I had to add some delays depending on the file's size. Maybe it's the same case for the core, the add-on demands the informations too soon (sometimes the core returns well the song type). I'll try to debug xbmc
(2023-08-23, 13:47)hakkinenvthh Wrote: [ -> ] (2023-08-23, 11:38)pkscout Wrote: [ -> ] (2023-08-23, 08:17)hakkinenvthh Wrote: [ -> ]Sorry, I'm new here, I reposted the logs in the below link (I can't edit my first post)
https://paste.kodi.tv/uceraxices.kodi
Many thanks for your help!
Kodi core returned unknown as the type, so that's what we have to work with on the addon side. I can't say why core did that, especially with only a log snippet. We really need a full and complete log, not just the snippet. Put Kodi in debug mode, restart Kodi, duplicate the issue, and then put the entire log in pastebin. Maybe that'll show something that will tell us why core is doing that.
Yeah you are right, no problem when we can treat it on the add-on side. I notice that when I call the method "GetProperties" on the player to get the current stream 's informations with some *.dsf or *.dff files, it takes time so I had to add some delays depending on the file's size. Maybe it's the same case for the core, the add-on demands the informations too soon (sometimes the core returns well the song type). I'll try to debug xbmc
There is logic is the add-on to wait for certain video stream types to get results, and you can change the wait time in the settings. If you find that waiting gets you a result eventually for those files, I can probably add the same logic for audio. The drawback is that, as currently written, it's all or nothing. You either have a delay for everything or nothing, and that could mean a delay in triggering whatever action you want for audio. I might be able to do something where if it gets no result or unknown that it waits and tries again though.