A command like spc seek should be implemented with the ability to give an integer from 0 to the length of the song in seconds, which will then seek to that position in the currently playing song.

Currently, the workflow to build and publish new releases is very repetitive, with a manually defined job for each OS and arch. It would be nice to instead have these arch/OSes defined in a matrix instead.

Goify appears to choke on the auto-generated config file with the following error output (happens with both help and auth subcommands):

Using config file: /home/dhscholb/.config/goify/config.yaml
ERROR: logging before flag.Parse: F0525 16:51:33.928019  938724 root.go:103] unexpected end of JSON input
goroutine 1 [running]:
github.com/golang/glog.stacks(0xc0000bc000, 0xc000136140, 0x48, 0x9c)
        /home/dhscholb/src/go/src/github.com/golang/glog/glog.go:769 +0xb8
github.com/golang/glog.(*loggingT).output(0xe25600, 0xc000000003, 0xc000129180, 0xdcf7aa, 0x7, 0x67, 0x0)
        /home/dhscholb/src/go/src/github.com/golang/glog/glog.go:720 +0x372
github.com/golang/glog.(*loggingT).printDepth(0xe25600, 0x3, 0x1, 0xc000125c98, 0x1, 0x1)
        /home/dhscholb/src/go/src/github.com/golang/glog/glog.go:646 +0x129
github.com/golang/glog.(*loggingT).print(...)
        /home/dhscholb/src/go/src/github.com/golang/glog/glog.go:637
github.com/golang/glog.Fatal(...)
        /home/dhscholb/src/go/src/github.com/golang/glog/glog.go:1128
github.com/dvdmuckle/goify/cmd.initConfig()
        /home/dhscholb/src/go/src/github.com/dvdmuckle/goify/cmd/root.go:103 +0x3a5
github.com/spf13/cobra.(*Command).preRun(0xc0000e2dc0)
        /home/dhscholb/src/go/src/github.com/spf13/cobra/command.go:872 +0x49
github.com/spf13/cobra.(*Command).execute(0xc0000e2dc0, 0xe41f98, 0x0, 0x0, 0xc0000e2dc0, 0xe41f98)
        /home/dhscholb/src/go/src/github.com/spf13/cobra/command.go:808 +0x145
github.com/spf13/cobra.(*Command).ExecuteC(0xe1c440, 0x43d30a, 0xddeca0, 0xc000000180)
        /home/dhscholb/src/go/src/github.com/spf13/cobra/command.go:950 +0x349
github.com/spf13/cobra.(*Command).Execute(...)
        /home/dhscholb/src/go/src/github.com/spf13/cobra/command.go:887
github.com/dvdmuckle/goify/cmd.Execute()
        /home/dhscholb/src/go/src/github.com/dvdmuckle/goify/cmd/root.go:52 +0x31
main.main()
        /home/dhscholb/src/go/src/github.com/dvdmuckle/goify/main.go:21 +0x20

Tested on 4ad9a78 (which is currently master).

The Cobra library appears to have a flag, -v, that lets you pass a log level to the program. I don't believe this does anything on its own without additional implementation. Currently, all error logs are done via glog, and thus lead to some very verbose errors, verbosity that might lead to confusion. While the logs from glog are useful when debugging, they aren't very useful to the end user. Therefore, it would be good if -v could be used to conditionally set if we're logging with glog. If verbosity is up, use glog, otherwise, print the error and exit with status 1. This may best be implemented with a wrapper function that takes in an error and does the check for verbosity. This wrapper function would best fit in the cmd/helper module/package.

https://github.com/dvdmuckle/goify/blob/e0832a4c29879ab6a66a3f2b1b8de08b1da593d8/cmd/helper/authHelp.go#L97-L100

Spotify recently added another kind of dynamically generated playlist like Discovery Weekly, called the "daylist." This refreshes at different times over the day, and it would appear a daylist is unique both to the time of day as well as the day of the week. It would be a welcome addition to be able to save the daylist, much like how one can already save the Discover Weekly playlist.

More on the daylist feature from Spotify: https://newsroom.spotify.com/2023-09-12/ever-changing-playlist-daylist-music-for-all-day/

In testing on a very slim Ubuntu instance, it appears that the Ubuntu build does not install something that implements org.freedesktop.secrets. It would appear that gnome-keyring implements this, but there are other implementations as well. I don't know enough about Ubuntu packaging to see if there's a way to generally specify any package that implements org.freedesktop.secrets. If there is, I'd like to go that approach, otherwise a decision needs to be made on what should implement org.freedesktop.secrets, hopefully something that's distribution agnostic.

https://github.com/dvdmuckle/goify/tree/master/cmd/root.go#L110-L110

Whenever an "online" command is run (any making a Spotify API call), we should check to see if the token is expired, and if so, renew it. Currently we do an in-memory renew of the token every time the API is called.

The branch debian/sid has some WIP code created by dh-make-golang to create a debian package for this project. I haven't been able to completely get it working myself, but ideally I'd like to automate the package creation using a GitHub action. The ultimate goal is to be able to install this package via apt-get with a repo hosted either on GitHub or elsewhere (S3?), and have that repo auto-updated any time a new release is created.

There's a v2 of https://github.com/zmb3/spotify out. It removes a number of functions used and reworks a couple others. Moving over to this library is no small feat, however it looks to be doable by someone unfamiliar with the code. The hardest part looks to be some of the things around auth, everything else looks to be about the same.

Running in both a multipass Ubuntu virt, and on a personal metal server, this error pops up when running spc auth

Error: Error saving token to keyringfailed to unlock correct collection '/org/freedesktop/secrets/aliases/default'

This looks to do with how the login keyring is not created by default for headless users. This might just require additional instructions for headless users to create this keyring, as opposed to a code fix.

spc search artist should be able to function and play the most popular tracks by the artist, and then play shuffled songs by the artist.

Hints
See https://pkg.go.dev/github.com/zmb3/spotify?tab=doc#Client.GetArtistsTopTracks and https://pkg.go.dev/github.com/zmb3/spotify?tab=doc#Client.GetArtist. Also check how spc search tracks functions in terms of queuing up additional songs by appending a spotify.URI to the list of songs to play.
Deliverable
New branch with this functionality added to the search command.

Error checking in the config-handling code needs to be updated to fail gracefully. See #7 as an example.

Currently, we are using COPR to build RPMs of spc for various versions of Fedora. However, because we're the webhook with SCM builds, things are a little broken as with each push of code, a new build is kicked off, with the source being whatever is in that push. We don't want this, ideally we want an automated system that builds a new package on ever release/tag. Configuring the webhook to trigger on a tag or release didn't work, so a different system will be needed. Potentially this may be a GitHub action.

One other issue is that COPR/go-rpm-macros with SCM builds don't like having v at the beginning of the tag. However, Debian packaging with dh-make-golang, which is not yet implemented, does want this, and expects it. One fix would be to maintain version tags with both v and without. That fix isn't really ideal however, and it would be preferred to keep one kind of tagging in place.

Done Criteria
Fix Fedora COPR builds so they trigger on either a release or tag, and satisfy the needs of both Fedora and Debian (not yet implemented) packaging.

The README needs a section to explain how to set up authentication for your local goify instance (e.g. how to obtain the client key and secret and where to configure them).

The current method of creating the config file relies too heavily on the root command. As a user, it would be nice to be able to configure goify either with goify config --clientid clientid --secret secret or using env variables.

Current, we use a PPA to build and publish .deb packages for Ubuntu Jammy. While this is the latest LTS version of Ubuntu, it would be nice to automatically build packages for more Ubuntu versions (namely the latest non-LTS version supported). While this can be accomplished locally, ideally this would be rolled into the automation currently configured to push sources to Launchpad for build.

The spc switch command can write to config the device to use for commands, switch to a device, and start playback for it, but it cannot just write to config the device to use. This should be implemented behind a flag of some kind.

For the spc search track command, after the initial searched for song is played, related songs generated by Spotify are added to the opts.URIs variable passed to PlayOpt(). While this works as expected, the side effect of this is the recommended tracks to be played are not visible in the Spotify app. Judging from the docs for the zmb3/Spotify library, this may be remedied by instead using QueueSong(), or specifically QueueSongOpt(), to queue up at least the recommended tracks after the initial play of the searched track. Also worth testing if queueing all the songs, the search result song and the recommended songs, works in the same manner as now.