musescore
[MUSE HUB] Muse Hub is packaged as .deb which excludes non deb-based Linux distributions
I am running Fedora 36 and having the Muse Hub packaged as a deb is a bit of mess. I tried to unpack the deb file and manually install the files in the correct locations. This brought to permission issues (which are solved through a native installer) and had to run MH through sudo. The experience was horrible anyway. After having downloaded some sounds, they appear as not downloaded (get) in MH after restarting the application. The fonts are loaded in MU4 though.
I have repackaged the deb to rpm using alien but installing the converted rpm reports a missing dependency liblttng-ust.so.0()(64bit) The dependency is part of lttng-ust which is installed in Fedora but in its version liblttng-ust.so.1()(64bit) and it is not recognised.
My suggestion, although I am not a developer and have no experience in programming, would be to package the Hub as a universal package, such as appimage (which is already done with musescore). This would allow compatibility across linux distros and ensure the shipment of the required libraries.
Hi!
I have a similar problem, as I am using a fedora 35.
I could create a rpm with alien:
sudo alien --to-rpm --scripts muse-hub.deb
I had to install lttng-ust to fix depencies. Fortunately for me, fedora 35 still uses .0 version, and not .1. Maybe you could try installing the fedora 35 packages for lttng.
I also had to --force the installation of muse-hub.rpm, but this should be okay.
After all of this, I could run muse-hub: a brightly coloured window appears, offering several choices of instruments. Unfortunately, I couldn't download any instrument: when I try, I get the very unhelpful error:
Something went wrong, please try again later
I'll open another bugreport about these problems. But please tell me if you manage to get muse-hub working on a fedora!
Éric Brunet
If possible, it would be best to distribute MuseHub as a distro-agnostic package. Flatpak is the favorite of most everyone that doesn't work for Canonical, at least that's my impression, and its certainly my favorite.
If a Flatpak isn't possible, then I'd consider an .rpm and a .deb to be the minimum for any application, and the Arch-based folks can maintain their own repackaged repos.
It's important to make these packages available soon, especially if you want to be well tested on the distros that will become dominant in the future: Ubuntu is falling out of favor as the Beginner's Distro and Fedora-based and Arch-based distros are on the rise among end users. I'm an engineer, not a developer, so while I feel qualified to report bugs in adequate detail, I don't feel confident enough to finagle a deb into an rpm.
tl;dr: Flatpak plz
@EB2000 I don't want to mess up dependencies by installing older versions on top of the new ones. I got Muse Hub to work to some extent by extracting its content with the dpkg-deb command and then sudo copied every file in the right target destination. The only issue I have so far is that the Hub itself does not auto update. To download the sounds however, I must run sudo muse-hub-service before starting Hub.
That is a horrible workaround but at least I get to have Hub to download sounds.
I am also in favour of Flatpak but I would be happy with whatever universal package the developers feel comfortable working with. Appimage is not my favourite and I don't use snaps but I would be ok with both if that offered access for all Linux users. But seeing MuseScore packaged as appimage, makes me think that the competences are there already to quickly and easily have Hub packaged that way. I would also be happy with installing from tarball with an installer script. (but I don't know in that case how it works with dependencies). Deb and rpm ok too but it would mean more work for the developers, as they would have to package and test two builds
@sberla365 Good for you, you managed to make it work. I could install cleanly the muse-hub packages, but it doesn't work: it fails at downloading anything, see my bug #14325. I am really curious at what is so different between our two systems. Could you post, as an attachment, the contents of your logs /srv/muse-hub/logs/current.txt and of the instruments database /srv/muse-hub/downloads/Instruments/.instruments ? (I am assuming that you downloaded all the instruments.)
Thanks, Éric Brunet
@EB2000 Here are my logs. I downloaded everything but choir.
I am having troubles uploading -instruments, I will try later. Have you tried invoking the systemd service through sudo muse-hub.service and running sudo muse-hub-sevice before opening Hub? I cannot download (or even have my downloaded instruments recognised in the Hub) if I don't run muse-hub-service as sudo
Also, there was an update to Hub yesterday and tantacrul said we should run the latest of everything to make sounds work. The download link is on the .org announcement
Thanks! I think I am using the latest muse-hub (0.9.9.295) and, yes, the background service is running. I managed to make it work by doing two things: allowing connections to my computer from the outside on my router (UPnP) and by adding a /etc/ssl/certs/ca-certificates.crt file. Not sure what did the trick; it works, I am not changing anything anymore until I have downloaded everything. Thanks for the current7.txt; don't bother with the .instrument; I don't seem to need it anymore.
Currently, non-deb systems are not supported; this is a known issue. We plan to have official non-deb system support in a future release.
As mentioned in #14325, the certificate linking change is the important one to get it working.
sudo ln -s /etc/ssl/certs/ca-bundle.crt /etc/ssl/certs/ca-certificates.crt
I would advise against manually copying files around, as this is not a stable approach and can lead to the hub getting out of sync with the downloads (and causing more hard to debug issues :) )
I have managed to successfully install Muse Hub on Fedora 37 with alien and rpmrebuild. I converted it to RPM with
sudo alien --to-rpm --scripts Muse_Hub.deb, then used rpmrebuild -pe muse-hub-1.0.0.392-2.x86_64.rpm to remove the conflicting files the rpm command complained about when I tried to install the package from the %files section in the spec file. Finally, I installed it with sudo rpm -i --nodeps ~/rpmbuild/RPMS/x86_64/muse-hub-1.0.0.392-2.x86_64.rpm. Bear in mind the generated RPM's filename may differ for you.
The --nodeps argument was necessary because it complained about a missing file from lttng-ust even though I have the package installed and the file exists. After installing, the muse-hub service should be enabled with systemctl enable muse-hub and then systemctl start muse-hub. The service needs to be running in order to use Muse Sounds in MuseScore, for instance.
@quotepilgrim What is the version of Musescore that are you using, I was able to install Muse-Hub, but could not use it inside Musescore. Thanks!
(muse-hub is running)...
@charlesneimog The latest 4.0.0 AppImage, I've just downloaded it today and figured out this whole process. You can enable Muse Sounds under "view > playback setup". If it's greyed out, the service probably isn't running, so make sure it is with systemctl start muse-hub
It still seems that Musescore is not able to discover muse-hub-service here on Fedora 36. Certificates are fine, and Muse Hub is able to download the data. I tried to use strace -e trace=network ./MuseScore-4.0.0-x86_64.AppImage to better understand what could have gone wrong, but I haven't got anything worth noting.
I had to manually "unzip" musesampler-linux-0.3.1.17.zip found somewhere inside /srv/muse-hub/downloads/Installers/, which is actually a .tar.gz file onto /usr/local/lib64/ to make it work.
(version number in the file might differ)
One liner to do that, run as root (or with sudo): tar zxf "$(find /srv/muse-hub/downloads/Installers/ -name "musesampler-linux*.tar.zip")" -C /usr/local/lib64/ --keep-newer-files
I tried the alien approach detailed above on openSUSE Tumbleweed ~~but had no luck so far~~. I managed to build and rebuild the muse-hub rpm, but trying to install it yielded:
error: Failed dependencies:
liblttng-ust.so.0()(64bit) is needed by muse-hub-1.0.0.392-2.x86_64
Unlike @quotepilgrim, my system has version 1 of liblttng-ust rather than 0:
-rwxr-xr-x 1 root root 489K Oct 4 19:39 /usr/lib64/liblttng-ust.so.1.0.0*
Overriding this with --nodeps allowed installation, but then the service fails to start:
Dec 17 00:17:29 aegean systemd[1]: Started Muse Hub Helper Service.
Dec 17 00:17:29 aegean muse-hub-service[3541]: Stack overflow.
Dec 17 00:17:29 aegean muse-hub-service[3541]: Repeat 174473 times:
Dec 17 00:17:29 aegean muse-hub-service[3541]: --------------------------------
Dec 17 00:17:29 aegean muse-hub-service[3541]: at System.IO.FileSystemWatcher+RunningInstance+WatchedDirectory.Write(System.Text.StringBuilder, Boolean)
Dec 17 00:17:29 aegean muse-hub-service[3541]: --------------------------------
Dec 17 00:17:29 aegean muse-hub-service[3541]: at System.IO.FileSystemWatcher+RunningInstance+WatchedDirectory.GetPath(Boolean, System.String)
Dec 17 00:17:29 aegean muse-hub-service[3541]: at System.IO.FileSystemWatcher+RunningInstance.AddDirectoryWatchUnlocked(WatchedDirectory, System.String)
Dec 17 00:17:29 aegean muse-hub-service[3541]: at System.IO.FileSystemWatcher+RunningInstance.AddDirectoryWatchUnlocked(WatchedDirectory, System.String)
Dec 17 00:17:29 aegean muse-hub-service[3541]: at System.IO.FileSystemWatcher+RunningInstance.AddDirectoryWatchUnlocked(WatchedDirectory, System.String)
Dec 17 00:17:29 aegean muse-hub-service[3541]: at System.IO.FileSystemWatcher+RunningInstance..ctor(System.IO.FileSystemWatcher, Microsoft.Win32.SafeHandles.SafeFileHandle, System.String, Boolean, System.IO.NotifyFilters, System.Threading.CancellationToken)
Dec 17 00:17:29 aegean muse-hub-service[3541]: at System.IO.FileSystemWatcher.StartRaisingEvents()
Dec 17 00:17:29 aegean muse-hub-service[3541]: at System.IO.FileSystemWatcher.StartRaisingEventsIfNotDisposed()
Dec 17 00:17:29 aegean muse-hub-service[3541]: at System.IO.FileSystemWatcher.set_EnableRaisingEvents(Boolean)
Dec 17 00:17:29 aegean muse-hub-service[3541]: at Microsoft.Extensions.FileProviders.Physical.PhysicalFilesWatcher.TryEnableFileSystemWatcher()
Dec 17 00:17:29 aegean muse-hub-service[3541]: at Microsoft.Extensions.FileProviders.Physical.PhysicalFilesWatcher.CreateFileChangeToken(System.String)
Dec 17 00:17:29 aegean muse-hub-service[3541]: at Microsoft.Extensions.FileProviders.PhysicalFileProvider.Watch(System.String)
Dec 17 00:17:29 aegean muse-hub-service[3541]: at Microsoft.Extensions.Configuration.FileConfigurationProvider.<.ctor>b__1_0()
Dec 17 00:17:29 aegean muse-hub-service[3541]: at Microsoft.Extensions.Primitives.ChangeToken+ChangeTokenRegistration`1[[System.__Canon, System.Private.CoreLib, Version=6.0.0.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e]]..ctor(System.Func`1<Microsoft.Extensions.Primitives.IChangeToken>, System.Action`1<System.__Canon>, System.__Canon)
Dec 17 00:17:29 aegean muse-hub-service[3541]: at Microsoft.Extensions.Primitives.ChangeToken.OnChange(System.Func`1<Microsoft.Extensions.Primitives.IChangeToken>, System.Action)
Dec 17 00:17:29 aegean muse-hub-service[3541]: at Microsoft.Extensions.Configuration.FileConfigurationProvider..ctor(Microsoft.Extensions.Configuration.FileConfigurationSource)
Dec 17 00:17:29 aegean muse-hub-service[3541]: at Microsoft.Extensions.Configuration.Json.JsonConfigurationProvider..ctor(Microsoft.Extensions.Configuration.Json.JsonConfigurationSource)
Dec 17 00:17:29 aegean muse-hub-service[3541]: at Microsoft.Extensions.Configuration.Json.JsonConfigurationSource.Build(Microsoft.Extensions.Configuration.IConfigurationBuilder)
Dec 17 00:17:29 aegean muse-hub-service[3541]: at Microsoft.Extensions.Configuration.ConfigurationBuilder.Build()
Dec 17 00:17:29 aegean muse-hub-service[3541]: at Microsoft.Extensions.Hosting.HostBuilder.BuildAppConfiguration()
Dec 17 00:17:29 aegean muse-hub-service[3541]: at Microsoft.Extensions.Hosting.HostBuilder.Build()
Dec 17 00:17:29 aegean muse-hub-service[3541]: at Program+<<Main>$>d__0.MoveNext()
Dec 17 00:17:29 aegean muse-hub-service[3541]: at System.Runtime.CompilerServices.AsyncMethodBuilderCore.Start[[Program+<<Main>$>d__0, Muse.Service, Version=1.0.0.392, Culture=neutral, PublicKeyToken=null]](<<Main>$>d__0 ByRef)
Dec 17 00:17:29 aegean muse-hub-service[3541]: at System.Runtime.CompilerServices.AsyncTaskMethodBuilder`1[[System.Int32, System.Private.CoreLib, Version=6.0.0.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e]].Start[[Program+<<Main>$>d__0, Muse.Service, Version=1.0.0.392, Culture=neutral, PublicKeyToken=null]](<<Main>$>d__0 ByRef)
Dec 17 00:17:29 aegean muse-hub-service[3541]: at Program.<Main>$(System.String[])
Dec 17 00:17:29 aegean muse-hub-service[3541]: at Program.<Main>(System.String[])
Dec 17 00:17:29 aegean systemd[1]: Started Process Core Dump (PID 3553/UID 0).
Dec 17 00:17:29 aegean systemd-coredump[3554]: Process 3541 (Muse.Service) of user 0 dumped core.
Module linux-vdso.so.1 with build-id 970de97f7d924e6cb173826b468c62f9b9823963
Module libicui18n.so.71 with build-id 6e0626096dd138390c38fd4b458a6d32fe60a73a
Module libicudata.so.71 with build-id ebd95a91f2e475033431922b125ef73f06b64c3f
Module libicuuc.so.71 with build-id a705117f4d248b308cbb6ca389ed2200fc0b9e9a
Module libSystem.Native.so with build-id 548efd216c4ff31a0f12afc1230c1adb83e82768
Module libclrjit.so with build-id 76621d87c473f812e6b8a8ab7a603696870a1676
Module librt.so.1 with build-id 171849d55d724288e7caaa0dc35144c446d727da
Module libcoreclr.so with build-id ef0ddda91ebee8c2e34c71b868309023abb3fc24
Module libhostpolicy.so with build-id 9f51fac0df7192c2e1d758ad2fa4735b4d2f55c1
Module libhostfxr.so with build-id 44ac737f5dd4c1f89d74b8102c9844de264123fd
Module ld-linux-x86-64.so.2 with build-id b7d99dc295f74348b9ecbd1f2113c99e4e44af7f
Module libc.so.6 with build-id 8ad4b412bfd8652bf0aef6a72fc69d27544287de
Module libgcc_s.so.1 with build-id e89ad2ad12dd6e8d97dd5f6ba53607a0b28592b8
Module libm.so.6 with build-id 83bd89671653f9bd07c6ed75b54b25b433e03b0f
Module libstdc++.so.6 with build-id 7a436b925867386356c0f62aa821c2b4c774bb30
Module libdl.so.2 with build-id fa31f94cb2c76a30e88ee2b098bb5cde20db2cdb
Module libpthread.so.0 with build-id bb45cc90f80de5167e8483c9b4290077e9103d53
Module Muse.Service with build-id 94f8e8a984f521f76b60d7fe6dcdc0988484586e
Stack trace of thread 3541:
#0 0x00007fddac3536bc __pthread_kill_implementation (libc.so.6 + 0xa96bc)
#1 0x00007fddac3006f6 raise (libc.so.6 + 0x566f6)
#2 0x00007fddac2e9814 abort (libc.so.6 + 0x3f814)
#3 0x00007fddabfb99db n/a (libcoreclr.so + 0x5129db)
#4 0x00007fddabfb9910 n/a (libcoreclr.so + 0x512910)
#5 0x00007fddabc9d451 n/a (libcoreclr.so + 0x1f6451)
#6 0x00007fddabd7ae38 n/a (libcoreclr.so + 0x2d3e38)
#7 0x00007fddabf82dc1 n/a (libcoreclr.so + 0x4dbdc1)
#8 0x00007fddabf84aa5 n/a (libcoreclr.so + 0x4ddaa5)
#9 0x00007fddabf84876 n/a (libcoreclr.so + 0x4dd876)
#10 0x00007fddabfc0346 n/a (libcoreclr.so + 0x519346)
#11 0x00007fdd32f97ae1 n/a (n/a + 0x0)
I'm not sure if that was caused by the wrong version of liblttng-ust but the stack trace seems to suggest otherwise.
In any case, while starting the service via systemd fails in this manner, weirdly it works if I su to root and manually run muse-hub-service. At that point it fails with a certificate error until I run:
ln -s /var/lib/ca-certificates/ca-bundle.pem /etc/ssl/certs/ca-certificates.crt
Then restarting it seems happy, and I can then run muse-hub non-root to get the downloader UI, which seems to be successfully downloading sounds.
In my machine it is possible to download all sounds, but Musescore is not recognizing the Music Sounds.
I am on Fedora 37!
In my machine it is possible to download all sounds, but Musescore is not recognizing the Music Sounds.
I had this too, until I ran the command from @cesarizu above and then did sudo ldconfig to make sure the linker picked up the library (although this may well be overkill). This shows it working:
$ ldconfig -p | grep Muse
libMuseSamplerCoreLib.so (libc6,x86-64) => /usr/local/lib64/libMuseSamplerCoreLib.so
Then after restarting MuseScore it worked! My old scores sound amazing, so happy to hear this after waiting so eagerly for so long. Massive kudos to the MS team for this incredible leap forwards!
For me, if I save one score on Windows with MuseSounds, I am able to use musesonds on fedora. :)
While a lot of the above is about fedora in general, I am using fedora silverblue, so I am partially bound to the Flatpak ecosystem. It would be nice if this could also be integrated with the existing flatpak. :) I assume it may need some extra work there, though, as Flatpaks usually are somewhat isolated to each other.
Another solution would be to create an AppImage for Muse Hub. There is one for MuseScore, so why not Muse Hub?
It also might be a good idea to request MuseScore package maintainers from Fedora/openSUSE etc. to package Muse Hub too, if it's not too much trouble, and add it as a recommended package (becasue it is not an actual dependency for MuseScore.
Incidentally, could someone point out to me where the code for musehub is? I've tried searching for it in this repo and in the others musescore repos but just couldn't find it. I was planning on just compiling/installing it myself to use it on my machine.
Incidentally, could someone point out to me where the code for musehub is? I've tried searching for it in this repo and in the others
musescorerepos but just couldn't find it. I was planning on just compiling/installing it myself to use it on my machine.
Sadly it is closed-source (as of now).
It also might be a good idea to request MuseScore package maintainers from Fedora/openSUSE etc. to package Muse Hub too, if it's not too much trouble, and add it as a recommended package (because it is not an actual dependency for MuseScore.
Actually, the simplest solution would be for distributions to package the sound files and the muse-sampler library, and to skip musehub entirely.
As far as I understand, musehub's purpose is to download, install and check for updates sound files and the library. This is exactly the role of the package manager in any distribution.
The one originality of muse-hub is to also be a bittorrent server: this means that when you download a sound file, it might come from the computer of another user of muse-hub. Also, when other people download a sound file, it might come from your computer. Bandwidth is being shared between all users. Now, that made a lot of sense in early stages: those files are huge, and everybody downloading them at once could have strained the musescore servers without the bittorrent trick. But if the sound files are packaged by fedora/opensuse/debian/ubuntu/etc., they will be on their servers, not musescore's, and I don't understand the point of musehub anymore. Could someone enlighten me ?
Sadly it is closed-source (as of now).
I wonder why this fact seems to be so hidden. MuseScore has been so praised because it is a FOSS app, and yet they create this proprietary app that is required if you want to use extra features, but don’t announce that it’s closed source at all! It feels quite dishonest, there no mention of it being closed on the website or in any announcement I can see.
The quite basic support for Linux could be chalked up to simply not caring about Linux as much in general, but I can’t help but assume the worst and say they don’t want to distribute the components directly because they would like people locked into their ecosystem.
once again, that would be assuming the worst. I hope as much as anyone else that then simply haven’t gotten to making the app open source yet.
The status of Muse Sounds and Muse Hub as closed source is no secret, it’s been public knowledge for well over a year since first announced on the forums. So rather than speculate, you might amwabt to just search out the previous announcements and discussions over the past year or two.
The status of Muse Sounds and Muse Hub as closed source is no secret, it’s been public knowledge for well over a year since first announced on the forums.
Apologies if this sounds harsh, but being in the forums is not the same as being publicly recognized by the project itself. Musescore likes to market itself as being free and open source, yet it won't clearly disclose a very relevant part of its software is closed source. Saying "you can find out if you search the forums" is not a decent answer to this.
In my opinion, musescore can be fully open source, stop marking itself as such, or put a clear, explicit, visible disclaimer that Muse Hub is not open source. What's currently happening is that musescore wishes to benefit from the publicity of being open source, without fully being so.
Muse Hub is not MuseScore and entirely optional, just like any VST is entirely optional or any soundfont is.
In the meantime, the Muse Hub team has their own support tracker at https://musehub.zendesk.com/ so you might want to consider adding your voices to the existing tickets over there and/or create a new one there if relevant.
