Bug:Album metadata returns 'null' in ShoutCast with react-native-track-playere-dev

[BryonConley]

Describe the bug
While running the react-native-track-player, dev (Oct 26,2020) version using our Shoutcast stream, I am observing the album metadata return 'null; value. At our radio station we utilize special control tokens like "Promo:", "Sponsor:", "Banner:", "Logo:" and "Advert:", note the colon as part of our control token wich is allowed in the Shoutcast and tags. So when we have 'null' in our album tag when we are streaming that metadata, we will lose control of our radio app not sync-ing with our programming. The title and artist metadata are working fine. I have incorporated the metadata redundantly in two ways: I set up the mp3 ID3 tags for album, artist, and title as well as setting the mp3 file name like "album - artist - title.mp3" I've included a zipped folder with screenshots showing this file name (Frosty by Major Tom), and another screenshot showing the mp3 ID3 tag data, and finally our radio station screenshot showing the correct metadata for album, artist, and title. So iit appears to be an issue with the track-playerer not capturing the album metadata in our Android platform. I have not tested iOS, nor do I have the tools to test iOS at this time.

To Reproduce
Steps to reproduce the behavior:

1. use the "http://whsh4u-panel.com:14083/stream" as the streaming url.
2. set your browser to this address: https://rockitstudios.com/trop-rockit/
3. Scroll down with the browser until you see the Song Request section.
   a. fill in "Major Tom" as the Song artist.
   b. fill in "Frosty" as the Song title.
   c. Fill in the rest as you see fit, must all be filled correctly before huttung submit button.
4. Wait about five minutes (timer is set for 5 min +/- completion of previous track.

Environment (please complete the following information):
Run react-native info in your project and share the content.
$ react-native info
info Fetching system and libraries information...
(node:2488) Warning: Accessing non-existent property 'padLevels' of module exports inside circular dependency
(Use node --trace-warnings ... to show where the warning was created)
System:
OS: Windows 10 10.0.19041
CPU: (4) x64 Intel(R) Core(TM) i7-6500U CPU @ 2.50GHz
Memory: 6.92 GB / 11.86 GB
Binaries:
Node: 14.8.0 - C:\Program Files\nodejs\node.EXE
Yarn: 1.22.5 - ~\AppData\Roaming\npm\yarn.CMD
npm: 6.14.7 - C:\Program Files\nodejs\npm.CMD
Watchman: Not Found
SDKs:
Android SDK:
API Levels: 23, 29, 30
Build Tools: 28.0.3, 29.0.2, 30.0.1, 30.0.2
System Images: android-30 | Google APIs Intel x86 Atom
Android NDK: Not Found
Windows SDK:
AllowDevelopmentWithoutDevLicense: Enabled
AllowAllTrustedApps: Enabled
Versions: 10.0.19041.0
IDEs:
Android Studio: Version 4.0.0.0 AI-193.6911.18.40.6626763
Visual St
HR Services Album Null.zip
HR Services Album Null.zip

udio: Not Found
Languages:
Java: 1.8.0_261 - /c/Program Files/Java/jdk1.8.0_261/bin/javac
Python: 3.8.6 - /c/Users/Bryon/AppData/Local/Microsoft/WindowsApps/python
npmPackages:
@react-native-community/cli: Not Found
react: 16.13.1 => 16.13.1
react-native: 0.63.2 => 0.63.2
npmGlobalPackages:
react-native: Not Found

-8PJBOJB MINGW64 ~/RockitPlayerReact/Example
$

What react-native-track-player version are you using?
react-native-kit/react-native-track-playere-dev (Oct 26, 2020 install from the Github dev)
Are you testing on a real device or in the simulator? Which OS version are you running?
Android Studio Emulator only.

Code
Please, share the code that is causing the issue
Not much to the code to test this:
useTrackPlayerEvents(["playback-metadata-received"], async event => {
console.log("Metadata album/artist/title: ", album, "/", artist, "/", title);
---

What I get in return: "Metadata album/artist/title: ;null'/Marjor Tom/Frosty"
Three sscreenshots in zipped folder:
1. Filename_and_Tags1.png
2. Filename_and_Tags2.png
3. HR Services Broadcasted Metadata.png
HR Services Album Null.zip

[Guichaguri]

Technically not a bug, it was never intended to work like this.

title and artist are from the StreamTitle tag, url is from the StreamUrl. No other tag, afaik, is officially documented in the Icy protocol, so they are completely ignored. All other parameters are always null.

For more implementation details, see the original PR that brought this feature: #552

Let me know if this helps or not.

[BryonConley]

Thank you for your feedback. I'd like to rebut on your classification. if you don't mind. The Abstract statement for this package defines as a "Fully featured track player" and the description to this states the reason for "yet another music player" is to provide a more complete and full features... With this, I ague this is a bug against the vision of the project? Also, the position and duration algorithm seems to have the same shortcoming under the Shoutcast streaming. If you don't mind, sharing with me where I can go into the package and fix this? Some tech questions. is your split function filtering out the ":" colon character? As the streaming title (mp3 ffilename) does include the album and the extra " - ". We can switch to private channel to discuss the details on this and duration so my progress bar works correctly in Shoutcast. Thanks again for your reply and look forwarad to further discussions.

[BryonConley]

Also, the StreamTitle includeed the album name as part of the mp3 filename as "album - artist - title.mp3" This 'album - " may have been knocked off bt the track perhaps due to the ":" colon or other algorithms extracting the artist and title. Can you tell me where that code segment is? I'd like to go into either the lib (not seeing the split function on ' - ' there), and still hunting for the code procedure in the android/src area of react-native-track=player. Thanks

[Guichaguri]

We've discussed before about removing the split and keeping the whole StreamTitle under title, we'll definitely do that at some point, the module can't be opiniated like that.
Because radios can format their titles in any way they want, there is no "standard" way to parse it down into artist, title and album. I originally splitted by the " - " because that is how the majority of radios format the title.

If your radio includes the album in the stream title, it's your job to split it down, the module should only serve as a interface between native, standard APIs and react-native.

[Guichaguri]

The code is in the dev branch:
https://github.com/react-native-kit/react-native-track-player/blob/7ce3d08c9915a2d129a65c5f9427f16b264b7691/android/src/main/java/com/guichaguri/trackplayer/service/player/ExoPlayback.java#L404-L412
And in the v2 branch:
https://github.com/react-native-kit/react-native-track-player/blob/2f7ddf0cd68b4682cfbf506c0df6cf8ca1582b40/android/src/main/java/com/guichaguri/trackplayer/service/player/SourceMetadata.java#L89-L97

[BryonConley]

Thanks very much -- the exoplayer was the only one I didn't check. May I propose not to delete the split, instead, add a new tag call it streamTitle and just export the full streamTitle to that. so when we get the track tags, we can just access it through the same interface we obtain artist and title. Just my thought. Also, dpn't reject any characters from the streamTitle, if the radiostation can stream the given character in streamTitle, if your doing any filtering with [A-Za-z etc]+ in any regEx. Hopefully this will help you and your team. I'd be glad to help. Here in the US radio broadcasting industry there is actually a standard in giving streaming titles from the mp3 file name as I described above as "album - artist - title.mp3" which gets broadcasted as stream title without the ".mp3" extension. But, if we have the flexibility with receiving streamTitle, we can add additional things like duration etc. At our broadcasting company, we're not newbies -- we have some well known station manger(s) and leaders of the industry that have recently joined us.. Thanks again for following up and offering the links and documentation for me to make these chancges. I will have to do the same for iOS and windows too. Hopefully your links include those code files and locations to.

[BryonConley]

Forgot to mention.. when we create the file name that becomes the streamTitle, that is typically fallback mechanism in the case the mp3 metadata isn't beomg [rpcessed. I believe there is a Github streaming MP3 metadata parser for tags and duration as well as other auxillary tags broadcasted voluntarily such as genre and other items...

[BryonConley]

Thanks for the pointer and the links. I found the code and reviewed it. It is simple. Apart from the fact the album is null, I see that our radiostation server providers are 'skipping' some information which I will track down. Thanks again -- you've been very helpful. I do hope you consider my proposal to add 'streamingTitle' object property for all those on the streaming world can use the same native interface as we see fit.