My Live II versus Firmware 3.9 - Wonky .xpm Issue

Over the past few weeks since I upgraded to 3.9 firmware, I've run into several issues, but one in particular is absolutely driving me nuts. I've been troubleshooting a persistent "Load Program Failed" issue on my MPC Live II (Gen 1, gold colorway), across almost every installed expansion that I have on my machine. Leading up to this past weekend I tried many of the normal operations of resetting preferences, trying re-exporting from MPC 3 desktop, and a couple of other things, but ultimately reformatting the SSD, and still ending up with the same Load Program Failed error even after all of that. Thought it was the SSD going bad even though it was only installed back in March…nope, still same issue with another SSD. So I dived a bit deeper with it.

After spending about 14 hours this past Saturday performing controlled testing, I think we've narrowed the issue down considerably. This wasn't a typical "reinstall everything" troubleshooting session, performed byte-level comparisons of .XPM files, XML validation, SHA-256 hash comparisons, firmware regression testing, and controlled A/B testing across MPC Desktop 2.5, MPC Desktop 3, firmware 3.7 and 3.9, USB media, and two different internally installed SSDs. I used 3.7 as that was my last known stable configuration with zero issues.

The biggest finding so far is that under the tested configuration, firmware 3.9 consistently produced byte-level alterations to valid .XPM files written to the internal SSD through Controller Mode, while firmware 3.7 did not reproduce the behavior under otherwise equivalent test conditions. Can consistently reproduce a scenario where a known-good .XPM program remains byte-for-byte valid when exported to a USB drive, but becomes byte-altered after being written to the internal SSD while the MPC is running firmware 3.9 in Controller Mode, using MPC 3 desktop expansion manager to write the expansions to the installed SSD. Downgrading to firmware 3.7 and repeating the same transfer on the same hardware resulted in a byte-identical file that loaded correctly. We also confirmed that both MPC Desktop 2.5 and MPC Desktop 3 produce identical, valid XPM files when exporting to USB, suggesting the desktop export process itself is not the primary issue for the cases we tested.

I'm not claiming we found the definitive root cause —there are still unanswered questions, and this may affect only certain hardware or workflow combinations. I can’t use all the software available as they are work assets and don’t want to get into trouble with anyone. However, we started to document the testing investigation in an engineering-style report and gathered objective evidence including file hashes, XML comparisons, and regression testing between firmware versions to send on up to Akai (I’m sure nobody will even look at it though).

I'm interested in hearing from anyone running an internal SSD on firmware 3.9 (or newer) who might have experienced the same issue. If others can confirm or refute these findings, we may be able to give Akai a much stronger engineering case than simply reporting "Load Program Failed."

This reminds me of is back when I was an avionics engineer, we had an initialization failure across a lot build. Going through supply chain research, found that at the component level, a suitable substitute chip was used on a card that was causing issues with the firmware. I’m wondering if it is something similar that I’m experiencing with this thing.

I’m wondering if this is a way to start forcing folks to the Gen 2 going forward. Small issues during firmware, causing issues, making the average consumer consider throwing in the towel and getting a Gen 2…because I was there myself with all of this.

Do you have the same issues if you export as a 'track' file instead of XPM? XPM format was updated for MPC 3.9, changing it from the old uncompressed XML format used up to MPC3.8 to the newer style file format of gzip compressed JSON, so an XPM file created in MPC 3.9 is now a effectively completely different file format to those older XPMs.

To clarify, are you loading original 'MPC 2 style' XPM files directly from an existing pre-3.9 expansion and getting this 'program loading' error each time? Or are you getting these errors from XPM files created in MPC 3.9?

I’m wondering if this is a way to start forcing folks to the Gen 2 going forward.

I can confirm that I have yet to experience any issues loading older XPM files into three different gen 1 machines running 3.9. I'm afraid there no 'forcing gen 2' conspiracy at play here.

MPC-Tutor wrote:Do you have the same issues if you export as a 'track' file instead of XPM? XPM format was updated for MPC 3.9, changing it from the old uncompressed XML format used up to MPC3.8 to the newer style file format of gzip compressed JSON, so an XPM file created in MPC 3.9 is now a effectively completely different file format to those older XPMs.

To clarify, are you loading original 'MPC 2 style' XPM files directly from an existing pre-3.9 expansion and getting this 'program loading' error each time? Or are you getting these errors from XPM files created in MPC 3.9?

Correct, they changed that. I haven't tested track (.xpj) exports because the failure occurs before any project is involved. The failure is loading standalone drum program (.xpm) files directly from expansions into a drum track. However, that's a worthwhile test and I'll add it to the investigation. Due to a lack of time to build my own as always seem to have some pressing family escapade like travel soccer, I rely heavily on my expansions for the percussion.

For the second question, The symptom is broader. After updating into the MPC 3.8/3.9 timeframe, nearly every expansion I had installed on my internal SSD began exhibiting "Load Program Failed" when loading drum program (.xpm) files. This includes multiple Akai expansions and partner expansions (Native Instruments stuff, F9, Vault 2.0, Deep House, Techno, etc.). The only drum programs that consistently loaded were the factory-installed kits located in the User folder.

I focused on a handful of expansions because they provided controlled A/B test cases, not because they were the only affected expansion content. For reference, I used .xpm's from Techno, Deep House, Vault 2.0, and F9 Origins Classic House as representative samples for byte-level comparison and regression testing. In every case where we had an untouched reference, we compared original files against the versions on the internal SSD.

One clarification regarding the XPM format change: the XPM files I compared from the expansions remained valid XML when exported from both MPC Desktop 2.5 and MPC Desktop 3 directly to a USB drive and SD drives. The deviation occurs specifically with MPC 3 desktop coupled with 3.9 firmware and the installed SSDs.

The byte-level corruption observed occurred only after writing those same files to the internal SSDs tested, while running firmware 3.9. That's why I'm very interested in understanding exactly when MPC 3.9 converts legacy content (if it does) versus when it simply copies it. If there is documentation describing when legacy expansion XPMs are migrated to the newer format, I'd genuinely like to read it because that may help explain part of what we're seeing.

One specific .xpm from an F9 expansion threw another odd wrench during testing as well. The healthy .xpm had 4 effects applied. No issue under 3.7 loading as it's one of my "go to's", but under 3.9, same error. During the testing day, I tested exporting to USB via the the save program method that was seeming to work for 3.9, but it still did not work. I removed the 4 effects that were applied to this specific .xpm via the expansion, and then retried the export, it worked no issue. Really odd on that one, as if 3.9 could no longer map out the effects, but this is a separate indexing issue from my primary one, or possibly the new .json format?

That's why this really started reminding me of an issue back during my engineering days, where we had a particular lot of card-level issues that failed on initialization. Only impacted about 250 units, very small population in the grand scheme of it.