Forum Replies Created
10. September 2019 at 18:50 #47069
All I did was write the image to USB instead of SD, connect to a Linux machine so I could edit the below files in a text editor (I’m using a Pi3 A+ so I don’t have a spare USB to connect a keyboard to when it’s running). It wasn’t running in AP mode properly (Would start for a moment then disappear) and without being able to connect to it to investigate due to 1 USB port, I disabled AP mode. I’m assuming it’s related to rc.local and/or the hard coded /dev addresses as the same image booted fine from SD.
Added to the end of /opt/max2play/wpa_supplicant.conf
auto_accesspoint_mode=0 (from 1)
Uncommented bottom 5 lines
I stuck the USB in the Pi, it rebooted and gave an error when resizing due to the hardcoded devices. I resized the partition manually via SSH, rebooted and it was good to go.
10. September 2019 at 15:46 #47067
- This reply was modified 3 years, 5 months ago by justinj.
I think the devs have given up on this, maybe there’s not enough money in it. I’ve had questions go unanswered that their „head developer“ was going to look into and now they’re asking you to fix it for them lol.
The only reason I can see thus far for it being incompatible is the devs hard coding devices in /dev
What they should be doing is something like a
cat fstab | grep " / "parsing the UUID and then getting it’s /dev mapping with something like
blkid | grep "PARSEDUUID"so that it doesn’t matter how it’s mounted (SD mounts as /dev/mmcblk* whereas USB is seen as a storage device and is thus mapped as /dev/sd* )
They have hard coded devices instead of using mount points or parsing on a number of scripts. If you update them to the correct path they work fine.
As much as M2P looks nicer and has a few other ‚premium‘ features, I am considering PiCorePlayer as M2P is requiring more patching than using to get going I’m afraid 🙁12. August 2019 at 15:07 #46758
So I scanned the partition and every single byte was blank. I guess that’s to be expected on an unmounted partition…
So I deleted the partition and resized using the expand filesystem function from within M2P web UI which resized it AND created the mystery partition again. I wrote the image back to the card that I had saved, resized the partition using raspi-config and no extra partition.
So this seems to be something that you have implemented that is either by design or has a bug. If it’s by design can you please elaborate what it is for? If it’s a bug, that’s in V2.48 so feel free to squash for future releases 🙂11. Juni 2019 at 2:42 #45645
After some more investigation it seems the scripts are not running correctly.
If I manually run the script /var/www/max2play/application/plugins/accesspoint/scripts/uninstall_accesspoint.sh it removes the AP mode and upon rebooting I can manually enter the WiFi details and have it connect. The problem I am now having is that they do not seem to be applying for all other settings too so I cannot apply settings under Rasberry Settings such as the sound card, CPU/GPU, Bluetooth, etc.
The same thing occurs with all other settings. After about 3 attempts it decided to take a static IP change that persisted after a reboot but I have no idea why these aren’t running. Apache is running as root so there should be no permissions reason these scripts aren’t running.
Any suggestions?9. Juni 2019 at 10:16 #45640
As good as Pihole is, MAX2PLAY is a media platform and I think we need to restrain from having all these other non-media related addons/plugins/extras added into it as it only causes bloat and more work for devs. As time is limited for everyone, that means that time would be taken away from some other task/bug fix that actually effects the media portion of M2P. As mentioned above, if you want Pihole (Let’s face it, it’s not something a lot of people will know how to setup even if it were a click to enable plugin) you can install it yourself as you have full access to your entire system.
The other alternative is Pi’s are cheap, you can run it on a second Pi so as not to slow down any media related functions that might possibly introduce jitter in the M2P distribution.12. Januar 2019 at 16:50 #43555
So it appears to be an issue with variable packet sizes from the HTC Connect app. Issue has now been fixed in the 104.4 version of Shairtunes https://github.com/philippe44/ShairTunes2
Not sure what’s needed for you to pop that into your repo/image but it’d be good to update M2P for others that might have the same issue and not know how to update manually.12. Januar 2019 at 1:16 #43546
Sorry it is to do with Shairtunes. So many similar names I listed the wrong one.
It works fine with Shairport direct to the M2P device but I want to sync the audio between rooms so I need to use Shairtunes which is what I’ve played with the buffer and encoding settings of to no avail.10. Januar 2019 at 15:15 #43424
I can’t see what it could be in the HTC Connect software as there is NOTHING being changed on the phone at all. Even if both Shairtunes and Shairport use the same core, there has to be some kind of buffer setting or similar causing this. It’s not the Pi as I’ve tried the Pi, NAS and Windows machine as the LMS server and the Pi and Windows machine as receivers.
I’ve played with the buffer settings in Shairport options but are there some other options somewhere? Perhaps hidden from normal view?10. Januar 2019 at 10:50 #43383
Yes I did post there too as I couldn’t initially post here. I’m thinking the issue has to be outside of the HTC seeing as how I can use Airplay from HTC Connect (So connecting it exactly the same way from the phone’s perspective) to Shairport on M2P and my old Mopidy install without any issues. The only variable in this situation has been Shairport Vs Shairtunes. I did try from an older HTC device (Just to be thorough in by debugging before posting) and achieved the same bad result (and success via Shairport).