joshkunz / ashuffle Goto Github PK

I would like to be able to specify alternate host or port on the command line with options like --host and --port. The env MPD_HOST=... syntax gets a little tiresome.

For example i would send command to my i3bar to refresh current_song widget.

Raspberry Pi OS (formerly Raspbian) is only built in a 32-bit variant, even though the more recent raspberry pis are running 64-bit compatible chips. This means that our aarch64 release is likely not useful to a majority of Raspberry Pi users. We should release a 32-bit ARM version as well.

Hi,

I was looking through some of the user requests from the moOde community about Auto Shuffle and a a fairly common one is to have the ability to only include certain genres for example only Genre = Classical.

Currently the only way to achieve this that I'm aware of is by using --exclude to exclude all but the desired genre.

If there were a --include option it would make this very easy.

-Tim

In order to have ashuffle ran at boot, I've configured following systemd service in /etc/xdg/systemd/user/ashuffle.service on my PC:

[Unit]
Description=Shuffle service for mpd
Requires=mpd.service
After=mpd.service

[Service]
ExecStart=/usr/bin/ashuffle

[Install]
WantedBy=default.target

Once #72 is resolved it may make sense to distribute such unit file together with ashuffle.

Hi,
I'm a big fan of Tim Curtis' moOde software but there is something I really don't like. I explained him the problem but he said I had to contact you because you are the developer of this feature.
I'm still struggling with your feature "Auto-shuffle". Don't get me wrong, it works without hickups.
But I don't like the fact that the whole library of moOde is taken into account. I want to limit to certain parts of my library.
Let me explain: I'm using moOde at home, but also at work. And at home I don't really care what plays. But since I have the same library at the office, I want to select certain parts to choose from in the auto shuffle.
I have "normal" rock in my library, but also pop, metal, heavy metal, punk, funk, disco...actually a bit of everything, even classical music. And also some live albums.
Now, everything is well organized in different categories, folders and so on, all with year, genre, cover art....
So the problem now is, that at the office I'm not allowed to play for instance Rammstein, or even Metallica. Classical music is also not appreciated (dunno why, but hey...).
What I want is, since everything is well categorized, is to activate auto-shuffle, and in that window select the folders that I want into this auto-shuffle feature.
I really believe you should think about this. The feature Auto-Shuffle as it is now, is really useless at the office, because I constantly need skipping numbers.
What do you think? Please let me know asap...
Thx for your time!
Johan

Likely has to do with how we calculate when a song is done playing.

Steps to reproduce:

1. run mpc consume on
2. run ashuffle
3. wait till the first song is done playing. At this point ashuffle should queue and begin playing another song, but instead play stops.

I was having some trouble building ashuffle on FreeBSD 11.2. I confirmed that I have libmpdclient installed and its .h files are available on the system. For some reason, though, I think that maybe they're not getting passed to CC?

[freebsd@icecast-source ~/ashuffle]$ make
 CC ashuffle
ashuffle.c:2:10: fatal error: 'mpd/client.h' file not found
#include <mpd/client.h>
         ^~~~~~~~~~~~~~
1 error generated.
*** Error code 1

Stop.
make[1]: stopped in /usr/home/freebsd/ashuffle/src
*** Error code 1

Stop.
make: stopped in /usr/home/freebsd/ashuffle

Running make -d A reveals that the actual command being run is cc '-std=c99' -Wall -Wextra -pedantic ashuffle.c -o ashuffle, which doesn't look like it's being passed any of the libraries.

Then I tried running gmake instead, which worked:

[freebsd@icecast-source ~/ashuffle]$ gmake
gmake[1]: Entering directory '/usr/home/freebsd/ashuffle/src'
 CC ashuffle.o
 CC args.o
 CC rule.o
 CC shuffle.o
 CC list.o
 CC getpass.o
 CC ashuffle
gmake[1]: Leaving directory '/usr/home/freebsd/ashuffle/src'
 COPY ./src/ashuffle .
[freebsd@icecast-source ~/ashuffle]$

But when I went to make install, I ran into another issue:

[freebsd@icecast-source ~/ashuffle]$ sudo gmake install
gmake[1]: Entering directory '/usr/home/freebsd/ashuffle/src'
gmake[1]: 'ashuffle' is up to date.
gmake[1]: Leaving directory '/usr/home/freebsd/ashuffle/src'
 COPY ./src/ashuffle .
install -t /usr/local/bin ashuffle
install: illegal option -- t
usage: install [-bCcpSsUv] [-f flags] [-g group] [-m mode] [-o owner]
               [-M log] [-D dest] [-h hash] [-T tags]
               [-B suffix] [-l linkflags] [-N dbdir]
               file1 file2
       install [-bCcpSsUv] [-f flags] [-g group] [-m mode] [-o owner]
               [-M log] [-D dest] [-h hash] [-T tags]
               [-B suffix] [-l linkflags] [-N dbdir]
               file1 ... fileN directory
       install -dU [-vU] [-g group] [-m mode] [-N dbdir] [-o owner]
               [-M log] [-D dest] [-h hash] [-T tags]
               directory ...
gmake: *** [Makefile:18: install] Error 64

I had to modify this part of the main Makefile to adjust to how install seems to work on FreeBSD:

install: $(BIN)
        install $(BIN) $(prefix)/bin/$(BIN)

This got it to work:

[freebsd@icecast-source ~/ashuffle]$ sudo gmake install
gmake[1]: Entering directory '/usr/home/freebsd/ashuffle/src'
gmake[1]: 'ashuffle' is up to date.
gmake[1]: Leaving directory '/usr/home/freebsd/ashuffle/src'
 COPY ./src/ashuffle .
install ashuffle /usr/local/bin/ashuffle
[freebsd@icecast-source ~/ashuffle]$

It would be nice if future revisions of ashuffle were ready for FreeBSD out of the box. Thanks again for all your hard work on this piece of software!!!

Hi,

I really like auto-shuffle with my mo0de audioplayer (raspi 3 + allo boss).
But it seems that the mpd crossfade feature dosn't collaborate well with ashuffle.

Is there an easy way to tell ashuffle to add a new song to the playlist, as soon as the second to last song has already finished (and not the last one)? Than there would constantly be one file left as a "buffer" in the playlist and in this case I think that the crossfade would work fine.

That would be a killer feature for those like me who like three things:

• shuffle playback
• crossfade
• really big playlists

Thank you very much.

When starting ashuffle, it adds a random song to the playlist and immediately starts to play it. This makes my PC automatically start playing at each boot, since I have it configured to start mpd and ashuffle at boot as shuffling through library is how I usually use mpd.

It would be really great to be able to disable automatic playback at ashuffle's launch.

I am experimenting with a web radio so I have a continuous broadcast of a large library playing at random with ashuffle.

Sometimes a file is not found (did not find the reason yet, maybe just need an mpc update to run).

In such cases, the playlist is started over and replayed. If I delete the unfound file and play the last track on the playlist, then ashuffle takes over again.

I would expect/like ashuffle to skip through the unfound file and pick another one instead, and in any case to keep on going.

I use ashuffle with a queue buffer of 1 to allow mpd crossfade.

Hi great application for MPD works great except I have one issue.

ashuffle tells me it cant play the track after adding a new song. Seems to be related to the password.

I use ashuffle with the command: env MPD_HOST="[email protected]" MPD_PORT="6600" ./ashuffle

When the playing track finishes then it adds a new track then wont play it.
I get the error: MPD error: you don't have permission for "play"

The password I am using is correct and works on all my mpdclients.

I am using the newest MPD build 0.21.3

In order to pick a random song out of the MPD library, ashuffle stores a list of all of the user’s songs in-memory. In memory-constrained environments, users with large libraries can experience OOMs or other crashes.

I think the most straightforward implementation would just be using temporary files and something like cdb. The source is public domain, and should be easy to embed in ashuffle.

Now that ashuffle supports building through meson. We should remove the old makefile. This will be done with the next major release.

Hi,

I'm using a file with songs, that ashuffle should use (generated with mpc). The file has ~17.000 songs. I'm starting ashuffle like this: ashuffle --queue_buffer 2 --file /tmp/ashuffle-songlist.txt
After ashuffle has started the CPU usage of mpd goes up to 100 % (one core fully loaded) for several minutes (measured 8 minutes on last try). Time increases with longer song lists.
CPU is a i5-4570 @ 3.20GHz.

During this time no songs are added to the queue.

There probably is some communication between ashuffle and mpd about the song list. Why and can it be deactivated?

Right now, we performance test ashuffle startup (time to first enqueue) at <750ms for a 20k track library. This is still surprisingly slow. We should try and improve this.

I think a reasonable target would be <200ms startup with a 100k track library. That should be fast enough that the user never notices ashuffle startup.

ashuffle reports connecting to MPD version 0.22.0

Does ashuffle have a version number? Can't report that.

Raspberry Pi 2B with MPD library on NAS via SMB and accessing through wifi.

Start ashuffle on the commandline:

ian@boombox:~ $ ashuffle
MPD error: Response line too large

The resulting MPD log at verbose level:

Feb 09 16:33 : client: [11] opened from 127.0.0.1:44122
Feb 09 16:33 : client: [11] process command "notcommands"
Feb 09 16:33 : client: [11] command returned 0
Feb 09 16:33 : client: [11] process command "listallinfo"
Feb 09 16:33 : client: [11] command returned 0
Feb 09 16:33 : client: [11] closed

This is supposed to be running with moode audio version 7.0.1.

This bug looks to be the same issue as

I am experimenting with a web radio so I have a continuous broadcast of a large library playing at random with ashuffle.

Sometimes a file is not found (did not find the reason yet, maybe just need an mpc update to run).

In such cases, the playlist is started over and replayed. If I delete the unfound file and play the last track on the playlist, then ashuffle takes over again.

I would expect/like ashuffle to skip through the unfound file and pick another one instead, and in any case to keep on going.

I use ashuffle with a queue buffer of 1.

In regards to formatting/style like it's specified in PR #62:

An .editorconfig file could define some of the style in a machine readable format,
so editors or IDEs with support for this (most have plugins) can load their settings from there
and developers won't have to change settings by hand.

These definitions include tabs vs. spaces, how many spaces for indents and more,
See: https://editorconfig.org/

Hi,

I have MPC databse fully loaded, but when I run ashuffle I just get "song pool empty".

Hi, I get the following error;
Picking random songs out of a pool of 8954
MPD error: Connection closed by the server

Standard mpd install on jessie 8

Thanks

This is probably a necessary prereq to #36 for at least some package repos.

It would be nice if you could pass a flag to ashuffle like --group album and it would do something like shuffle the albums instead of the songs individually. I don't really know what the best way to expose this would be.

Questions:

• What kind of groups would you want to express? Albums? Artists? Maybe combinations like Artist + Year?
• What does it mean to "shuffle a group". Do we play all the songs in that group? In what order?

Hi,
for some reason the queue_buffer argument does not work, when I launch ashuffle in background:
ashuffle --queue_buffer 2 &

Same problem when I pipe output to /dev/null:
ashuffle --queue_buffer 2 > /dev/null

In both cases songs are added to the queue, but only one song when the queue finishes. If I just start ashuffle --queue_buffer 2 in foreground there are always 2 songs at the end of the queue as expected.

ashuffle attempts to apply filter rules to the user's MPD library right at startup. This usually involves a round-trip to MPD per-song, which can have a substantial impact on startup time for users with moderately large libraries, as shown in issue #31.

This issue tracks the implementation of lazy filter rules for ashuffle, to ensure that ashuffle can quickly start queueing music, regardless of the size of the user's library.

off-the-cuff ideas for how this could be achieved:

• Use threads to evaluate songs/song-uris against the filter rules.
• Only attempt to evaluate filter rules at queue time (i.e. right before playing, or maybe right before they are added to the window). This way we can avoid a dependency on threads, but we only need to check a couple songs.

Specifically, test for being able to build without submodules. See issue #37.

Hi,
I've tried to build ashuffle on Alpine Linux with musl C library. Following error comes up:

make[1]: Entering directory '/root/ashuffle-1.0.1/src'
 CC getpass.o
getpass.c:23:13: error: conflicting types for 'getline'
 static void getline(char ** lineptr, size_t *n, FILE *stream) {
             ^~~~~~~
In file included from getpass.c:5:
/usr/include/stdio.h:153:9: note: previous declaration of 'getline' was here
 ssize_t getline(char **__restrict, size_t *__restrict, FILE *__restrict);
         ^~~~~~~
make[1]: *** [<builtin>: getpass.o] Error 1
make[1]: Leaving directory '/root/ashuffle-1.0.1/src'
make: *** [Makefile:8: ashuffle] Error 2

I've fixed it by replacing getline with mygetline in getpass.c

When using ashuffle on a collection of about 80,000 songs on a Raspi with 512 MB RAM, I got the following error in mpd.log:

May 27 17:29 : buffered_socket: error on client 2: Output buffer is full

And ashuffle says:

MPD error: Connection closed by the server

Is the collection too big? The Raspi's memory too small? Both? :)

The meson.build file with default options includes the t/meson.build which searches for libtap/tap.c .
The latter is not included in githubs release tarball, thus ashuffle fails to "configure" with the following error:

t/meson.build:2:0: ERROR: File libtap/tap.c does not exist.

Steps to reproduce:

1. Go to github releases
2. Download "Source code (tar.gz)" from assets
3. Unpack, cd into it
4. run meson build
5. Observe above error

Workaround: Replace Step 4 with: meson build -Dtidy_mode=true , but this disables tests...

I get meson error while trying to build ashuffle 3.5.0 on RPI3 following step-by-step instructions.

Here is the meson log:

`Build started at 2020-06-08T18:40:01.583197
Main binary: /usr/bin/python3
Python system: Linux
The Meson build system
Version: 0.49.2
Source dir: /home/pi/ashuffle
Build dir: /home/pi/ashuffle/build
Build type: native build
Project name: ashuffle
Project version: undefined
Sanity testing C compiler: cc
Is cross compiler: False.
Sanity check compiler command line: cc /home/pi/ashuffle/build/meson-private/sanitycheckc.c -o /home/pi/ashuffle/build/meson-private/sanitycheckc.exe
Sanity check compile stdout:

Sanity check compile stderr:

Running test binary command: /home/pi/ashuffle/build/meson-private/sanitycheckc.exe
Native C compiler: cc (gcc 8.3.0 "cc (Raspbian 8.3.0-6+rpi1) 8.3.0")
Sanity testing C++ compiler: c++
Is cross compiler: False.
Sanity check compiler command line: c++ /home/pi/ashuffle/build/meson-private/sanitycheckcpp.cc -o /home/pi/ashuffle/build/meson-private/sanitycheckcpp.exe
Sanity check compile stdout:

Sanity check compile stderr:

Running test binary command: /home/pi/ashuffle/build/meson-private/sanitycheckcpp.exe
Native C++ compiler: c++ (gcc 8.3.0 "c++ (Raspbian 8.3.0-6+rpi1) 8.3.0")
Build machine cpu family: arm
Build machine cpu: armv7l

meson.build:25:2: ERROR: Module "cmake" does not exist`

The "window" is the playlist of songs that are guaranteed to not repeat. This prevents instant-repeats, but allows repeats over a longer time horizon. It's currently hard-coded to 7 this generally works fine, but I think some users would like to tweak this, to allow more repeats, or make repeats even less likely. There's not technical reason we can't make this a flag, so we should probably expose it.

My one reservation about this... Most users probably don't care about this flag. This flag should be easy to ignore for most users. Maybe instead of a top-level flag, we can add some "tweaks" mechanism. By default these won't show up in --help, but if a user cares, they can look them up and mess with them. Something like --tweak window-size=100 perhaps...

Found this in a post on the MoOde audio forums. Looks like when I was adding --group-by I forgot to update the loader that is used when the MPD database reloads. We need to plumb the loader through to the update command.

We should add a test for this as well.

There are now a good number of shell scripts in the tree. We should have a consistent style, and lint these scripts as well. shellcheck seems like a good off-the-shelf option for listing.

Hi,

For ARM platforms are three separate binaries required or is there an easy way to compile the sources into a single binary that runs on arm6, 7, and 64?

-Tim

Hi. Love this software. I use it everyday.

I am trying to package it for the Void Repos. I had to add abseil-cpp to the repos and update gtest. These two build fine but ashuffle runs into issues. This is the output: http://dpaste.com/1YCK6XW

If you'd like to, you can look at the tentative templates for ashuffle and abseil-cpp.

I don't know what this means so any input would be appreciated. Thank you.

Edit

The previous problem seemed to be related to packaging abseil-cpp which I have managed to fix. But I get this error now: http://dpaste.com/02XRTS0

Looking at the source, looks like the function ends without returning but you assert that that situation would be unreachable.

Any advice on dealing with this would be appreciated. The links to the templates above have been updated. Thanks.

Edit 2

For now I have worked around that problem by adding [a patch[(https://github.com/kartikynwa/void-packages/blob/ashuffle/srcpkgs/ashuffle/patches/fix-werror.patch) that replaces the assert statement with a "return invalid argument" statement. If you can think of more elegant solutions feel free to let me know.

As far as I can tell this project doesn't offer any way to connect to a MPD instance that is password-protected. Is there any possibility that this can be implemented? I would love to use this software for a project I'm working on.

Thanks very much!

ashuffle already has an AUR repo (not maintained by me), but it would be good to also be included in say, the ubuntu release, and maybe brew?

Hi,
I am using moOde/MPD 0.21.16 together with ashuffle.
If the NAS (NFS) is mounted to the library, ashuffle stops running, giving the error message:
"Response line too large".
Any suggestions to solve this problem?
Thanks,
Regards, Herman

meson arguments:

meson --prefix=/usr --bindir=/usr/x86_64-pc-linux-musl/bin --sbindir=/usr/x86_64-pc-linux-musl/bin --libdir=/usr/x86_64-pc-linux-musl/lib --libexecdir=/usr/x86_64-pc-linux-musl/libexec --includedir=/usr/x86_64-pc-linux-musl/include --sysconfdir=/etc --datadir=/usr/share --mandir=/usr/share/man --default-library=shared --native-file meson-native.txt --wrap-mode=nodownload /tmp/paludis/build/media-sound-ashuffle-3.3.0/work/ashuffle-3.3.0

From meson logs:

Installing subprojects/absl/librandom_internal_distribution_test_util.a to /tmp/paludis/build/media-sound-ashuffle-3.3.0/image//usr/lib64

Hi there,

I use ashuffle in an automated, unsupervised environment. What typically happens is that I will forget about it for several months, and MPD will eventually crash when its playlist grows large enough, leading the automation to stop working and require MPD and ashuffle to be manually restarted. I cannot seem to find any information on the internet about a built-in configuration option for MPD that would allow it to remove old tracks from the playlist automatically. It would be great if ashuffle could contain this functionality, though I understand if it might be a bit too niche for what you're doing. Either way, thank you so much for all your hard work! It's been completely indispensable to me.

Hi there! Seeing that you've been doing all this work on a music-shuffling program, would it be relatively easy to add a mode that, rather than playing songs picked at random, randomly picks an album from the library, plays the album straight through, and then moves on to another randomly selected album?

Personally I find that full shuffle is often too jarring, and I like listening to albums all the way through, but it would be really nice if I could get a program to just keep that stream of albums playing without me having to think about what to put on! In case this does happen to interest you, I should point out that for usability, the full-album shuffle mode really needs to have simple ways both to skip the current song and to jump to another album immediately. (Sometimes you're just not in the mood for what the RNG picked.)

This is a feature I would have expected to be common in mainstream music players, but that hasn't been my experience.

Hi, I'm using the wonderful moOde to stream music from my NAS using a RPi3 and RPi3B+.
My collection of albums exceeds the number of 4200 with over 74000 songs.
When I now want to "ashuffle" through this complete library, ashuffle won't work anymore. This already happens when I have more than 42000 songs in my library. As soon as I start the random selection icon, I can see in SSH that ashuffle uses up to 99.9% of the CPU but after a minute the process ashuffle disappears from the list (Did it stop? Did it crash? I don't know).
So now I'm wondering: is there a limitation on the number of songs (42000 in my case, someone said 33000 on a PiZero) or is there a time limit, meaning if the system still hasn't selected a song after one minute, then the whole process stops.
Thx in advance for your fast response.

Johan

Issue Description
The following code fragment in ashuffle.c is failing for me (the fprintf on stderr have been obviously added by me for debug reason)

int try_first(struct mpd_connection * mpd, struct shuffle_chain * songs) {
    struct mpd_status * status;
fprintf(stderr, "before mpd run status 1...\n");
    status = mpd_run_status(mpd);
fprintf(stderr, "after mpd run status 2...\n");
    if (status == NULL) {
        fprintf(stderr, "STATUS IS NULL!!!...\n");
        puts(mpd_connection_get_error_message(mpd));
        return -1;
    }

Example error returned:

before mpd run status 1...
after mpd run status 2...
STATUS IS NULL!!!...
Connection closed by the server

Other info

pi@moode4b4:~ $ mpc version
mpd version: 0.20.0

Number of tracks in MPD library: 43291

Right now, the only way for most users to get ashuffle is by compiling the software from source. We should make this easier by also releasing binary distributions. Though, likely only targeting a subset of platforms.

Hi. I am trying to install ashuffle on a Raspberry pi zero. I already had libmpdclient2 installed (version 2.16-1). When I run ./ashuffle.armv6h-linux-gnueabihf I receive an error message "Segmentation fault". I also get this if I run as root. I'm sure that I am doing something wring, but I can't work out what.

Any ideas?

Thanks.

Duncan

It would be nice if users with ashuffle binaries could easily obtain the version from the binary itself. This issue tracks that feature.

I'm not sure if this is arch/build/environment dependent but I can sometimes get shuffle --queue_buffer 1 to complain it could not convert queue_buffer's argument (it happened for me when building with meson -Db_sanitize=address on arm7l linux gnu)

The reason for this is that strotul does not reset errno to 0 if there is no error, so the current way of checking errno only works if it wasn't EINVAL or ERANGE before.
There are multiple ways of solving this, for example reseting errno before calling strtoul should work in principle, but that won't complain if the user passes something that starts with digits e.g. --queue_buffer 42waswrong will not error.
The "correct" way of checking for strtoul success is to pass a endptr argument and check that it points to a nul byte; anything else and the string was not fully parsed.

(While looking at this, I also noticed we're not checking that there are enough arguments, e.g. ashuffle --queue_buffer does not error out either; it probably should)

Likewise, happy to submit a PR, but it's likely just as fast to fix directly - your call. Sorry for the "spam" :)

I am using the Android client M.A.L.P. which has the option of replacing the current playlist with an album. I assume that it uses something like mpc clear; mpc add ALBUM (which is how I do it in scripts as well) and I can't think of a better way to do this. In conjunction with ashuffle however this results in a random song being added inbetween because for a short moment the playlist is empty and thus ashuffle adds a new random song followed by MALP adding its album.

I'd like to propose that when ashuffle detects an empty playlist to have it wait a few milliseconds and check if the playlist still is empty and only then add a new random song.

Likely caused by a race with the player.

Steps to reproduce:

1. Start ashuffle
2. run mpc clear. At this point the music stops. (should ashuffle add another song here?)
3. run mpc add <song-file>. At this point, ashuffle will queue another song and begin playing it instead of the song we just added.

Hello!

The problem is that getline() is a standard library function. (defined in stdio.h) Your function has the same name and is thus clashing with it.

The solution is to simply change the name.

Thanks!