Non working All-Inclusive Search with GMusicAPI 9.0.0

[Bucklew]

Hello everyone,

got the following message while trying to search in the All-Inclusive Area:

[16-04-26 11:27:50.4454] Plugins::GoogleMusic::AllAccess::search (234) Not able to search All Access for "xxx": Python object has no method named search_all_access at /usr/local/lib/x86_64-linux-gnu/perl/5.22.1/Inline/Python.pm line 337.

Reverted the GMusicAPI back to Version 7.0 and everything works again: https://github.com/simon-weber/gmusicapi/releases/tag/7.0.0

Is this project even active anymore?

[askvictor]

The API has changed, this project hasn't. It looks like @hechtus has dropped out; @nick7634 has made some mods but the project is in a bit of a mess

[nick7634]

Yes, this project needs some serious updating as the methods in the GMusicAPI have changed a lot and this plugin has not been updated to match those new methods yet.

[Bucklew]

Thats kinda bad :(

Too bad my Python/Perl skills are so bad.

[SpartanTech]

Yeah, I've been working on this for a week actually with no previous perl experience and limited python. They changed search_all_access to search (all_access and search now return results in one API call), but there's something else going on. I think @hechtus prased data strange and because of that it's having a hard time even with the function name change. I can't tell if it's a dependency change or if googleapi is actually returning a different data structure than before.

I'm getting not an array reference errors after making the googlemusicapi changes, and trying to parse the data with my limited knowledge of hashes, lists, arrays, and dereferencing isn't getting me far.

Inline::Python for Perl doesn't allow keys to be used as they should, so I can't parse any *_hits results farther than the first sub-key. And it's not JSON formatted so we can't use a json parse without fixing the results.

Feel free to chime in anyone else. Fixing this would be a great help! @nick7634 nick, if you have any ideas, lemme know.

[askvictor]

May I propose a hard-fork of this repository (squeezebox-googlemusic-NG?) to be able to have our own issue tracker and ability to add developers/PRs where required? There seem to be a few people working on this, and probably some duplicated effort, and no central spot for discussion (I found this on StackOverflow: http://stackoverflow.com/questions/37535999/how-would-i-read-this-data-structure-in-perl-dictionary-hash-with-keys-containi?noredirect=1#comment62691348_37535999 )

Whatever development structure goes ahead would need to expect that people will drop out of developing this as other life priorities take hold (as has happened with @hectus, @nick7634 , and probably myself in the months to come :)

[kettenbach-it]

The new method "search" of gmusicapi returns the results in a dictionary with keys:

album_hits, artist_hits, playlist_hits, situation_hits, song_hits, station_hits, video_hits

containing lists of results of that type. (http://unofficial-google-music-api.readthedocs.io/en/latest/reference/mobileclient.html#search)

I'm not a perl expert, but I think the code in AllAccess.pm:

    eval {
        $googleResult = $googleapi->search($query, $prefs->get('max_search_items'));
    };
    if ($@) {
        $log->error("Not able to search All Access for \"$query\": $@");
        return;
    }
    for my $hit (@{$googleResult->{song_hits}}) {
        push @{$result->{tracks}}, to_slim_track($hit->{track});
    }
    for my $hit (@{$googleResult->{album_hits}}) {
        push @{$result->{albums}}, album_to_slim_album($hit->{album});
    }
    for my $hit (@{$googleResult->{artist_hits}}) {
        push @{$result->{artists}}, artist_to_slim_artist($hit->{artist});
    }

should be modified

[askvictor]

Fixed it! see https://github.com/squeezebox-googlemusic/squeezebox-googlemusic/commit/e6fa62d9da3bc7295023283ef5d25698737e5772

[deradam]

Works! Thanks for the awesome work @askvictor