Enhanced Submission Rules - don't scrobble podcasts / ebooks

[konsept]

Is it possible to support additional submission criteria such as excluding Podcast plays from scrobbling?

[inverse]

How would you determine what a podcast play is?

[konsept]

Genre?

[inverse]

Hmm this could work from a little reading that I've done. See this quote:

Nearly all podcasts use the genre "Podcast", which is not even included in the official ID3 genre list.

• https://auphonic.com/blog/2012/01/17/podcast-comparison-part-2-mp3-metadata-id3-tags/
• http://www.richardfarrar.com/what-id3-tags-should-you-use-in-a-podcast/

I don't know if track genre is being served up though. I guess it could be a proposition to extend sls integration mechanism.

[konsept]

Excellent. Yes, I too have seen Podcast used as the genre in nearly all of those I subscribe to. MediaMonkey maintains a Type field that classifies files as Music, Podcast, Video, and the like but this may be app-specific so I'm unclear on whether this is contained within ID3.

[tgwizard]

It isn't certain that SLS can read the genre data, or any other metadata except the track name, artist name, and album name. Perhaps also the duration.

Perhaps there is some other way to distinguish these kinds of tracks - duration > 30min? "[podcast]" in the name? Or something else.

It might be possible to configure in SLS to "dont scrobble tracks longer than X minutes/seconds". What do you think?

[inverse]

I guess having the ability to disable scrobbling for tracks that are longer then X would be a work around. Alternatively, in my opinion what feels better would be a blacklist filtering mechanism.

For example most podcasts I have seen come in a format similar to:

Laravel IO - Episode 15 - ActiveRecord, Laravel Haterade, DHH and Laracon Stuff with Taylor Otwell, Jeffrey Way, Mitchell van W

So perhaps allowing the user to specify some regular expressions of what to block. Which for the above would be something like ^Laravel IO - Episode \d+ - .+. What do you think of this?

[eligrey]

@tgwizard A bunch legitimate music and ambient tracks (that are not full albums or compilations) in my library are close to or over 30 minutes:

• The original Rainy Mood track (ambient, 34m 23s)
• Children In The City by A.M. Architect (music, 27m 54s)
• When Can (flavors mix) by Kettel & Secede (music/ambient, 45m 52s)
• 0181 by Four Tet (music, 38m 8s)
• Perlence subrange 6-36 by Autechre (ambient, 58m 35s)

If all the other data you can get is just track name, artist name, and album name, then unfortunately the best solution seems to just be a manually curated app blacklist (I assume you can figure out which app is sending the now playing notification?).

[inverse]

How do you think the handling of of a blacklist list feature should be handled? I feel we have one of two options.

1. Implement a global one
2. On a per app basis - although I've not looked into the architecture of that part of the application yet so I don't know if would lend itself to that without refactoring.

Opinions?

[eligrey]

The per-app basis would be pretty complicated for users to use, as I would imagine you would have to combine that with the filtering as you suggested before. I wouldn't be against it, but it would definitely have to be put in some advanced settings menu.

I would prefer the global one due to simplicity. This will cover for-purpose apps like podcast apps and audiobook apps like Audible.

[konsept]

I agree with @eligrey as I also have tracks longer than 30min. I think the regular expression idea by @inverse could work well if reading genre data in SLS is not an option. Probably support for multiple exclusion criteria would be necessary. For example, exclude both *Podcast* and *Episode* or the name of the podcast provider such as BBC*. From my perspective, I don't see the need for this to be app-specific but if you see a need, by all means.

[eligrey]

Also, to add to your filter list if you guys do decide to have default filters: ^Chapter\s*\d+$ on the track name will usually cover Audible audiobooks.

[inverse]

Yeah - I think a global one would be a better fit for the app and would certainly complicate things less for the end user.

[tgwizard]

Regexps are fine for advanced users, but how do we explain this to regular non-regexp users? Perhaps just a list of "don't scrobble if track contains any of these words"? What about album, and artist?

[tgwizard]

If anyone wants to look at the code, they intents broadcasted by the media players (containing the track info) is received by BroadcastReceivers such as https://github.com/tgwizard/sls/blob/master/src/com/adam/aslfms/receiver/AndroidMusicReceiver.java. The logic to filter tracks could perhaps be placed here: https://github.com/tgwizard/sls/blob/master/src/com/adam/aslfms/receiver/AbstractPlayStatusReceiver.java#L99 (after we check if we should scrobble this music app).

[modu]

I thought of printing all the keys of bundle received from default android music player and a podcast app . Can anyone find any criteria that we can use from this list to filter normal music from a podcast? Tried printing values of keys but app crashes From default Android music player app( from log)

" duration is a key in the bundle\ playstate is a key in the bundle\ currentContainerName is a key in the bundle\ artist is a key in the bundle\ domain is a key in the bundle\ currentSongLoaded is a key in the bundle\ preparing is a key in the bundle\ rating is a key in the bundle\ albumId is a key in the bundle\ currentContainerTypeValue is a key in the bundle\ currentContainerId is a key in the bundle\ playing is a key in the bundle\ streaming is a key in the bundle\ inErrorState is a key in the bundle\ albumArtFromService is a key in the bundle\ id is a key in the bundle\ currentContainerExtData is a key in the bundle\ album is a key in the bundle\ local is a key in the bundle\ track is a key in the bundle\ position is a key in the bundle\ currentContainerExtId is a key in the bundle\ supportsRating is a key in the bundle\ ListSize is a key in the bundle\ previewPlayType is a key in the bundle\ ListPosition is a key in the bundle\"

And from a podcast app named "podcast addict"

" 07-26 20:23:10.511: D/SLSBuiltInMusicAppReceiver(27211): Will read data from intent 07-26 20:23:10.511: D/DebugSLS(27211): duration is a key in the bundle 07-26 20:23:10.511: D/DebugSLS(27211): artist is a key in the bundle 07-26 20:23:10.512: D/DebugSLS(27211): playing is a key in the bundle 07-26 20:23:10.512: D/DebugSLS(27211): id is a key in the bundle 07-26 20:23:10.513: D/DebugSLS(27211): album is a key in the bundle 07-26 20:23:10.513: D/DebugSLS(27211): track is a key in the bundle 07-26 20:23:10.513: D/DebugSLS(27211): position is a key in the bundle 07-26 20:23:10.513: D/DebugSLS(27211): ListSize is a key in the bundle "

[oleg-sh]

This is a bit of an issue for me too. SLS scrobbles podcasts from Podcast Addict app so I switched to AntennaPod and since recently it also began to scrobble audiobooks from Smart AudioBook Player...

[a-r-db]

I might be able to do this with Dikamilo's #50

[a-r-db]

After researching, I don't think there is a method for obtaining which pkg is using audio so no way to control scrobbling except for filters.

[a-r-db]

478 <- see here for the patched code

479 <- see here for most recent released signed debuggable apk.

[a-r-db]

There is no clear cut criteria for detecting podcasts. I can however build a user generated words or symbols blacklist for tracks. I will add it to my developer todo list. PanoScrobbler Does Some Similar Handling