To be fair, the developers currently on staff are not the same as those that initially developed the 8000 software.
InMusic bought Denon afterwards and are left with picking up the support tab on the legacy firmware.
Development on the Prime series is much better, and lately much faster - I’d imagine a lot of curses are said whenever one of the devs needs to go back and fix something on the legacy 8000 code. The honest truth here is that the MCX8000 is legacy at this point and you’re lucky to have even gotten a 2.0 release, let alone ones after that.
Regarding the history bug, cost vs benefit of fixing it probably has it as a low priority because not many will be using the 8000 standalone, even fewer will use the history. Yes a beta test did take place but did Denon say they would fix that issue? If they did then your outrage is more understandable, otherwise fixing it might just not have been on the 2.5 release roadmap.
JonnyXDA, who bought Denon there and who wrote the software and who is working now and who is not working - it doesn’t interest me at all because i’m just a customer. It’s internal troubles of Denon, not my. I was pay for MCX8000 like others people. The MCX8000 is out of support? No. Therefore let’s they fix f***in history!
Lol I’m just giving you a bit of an insight as to my guess as what is going on internally. You may well be a customer but you also have a legacy product so expecting and demanding things without due understanding is naïve and foolish.
Prepare list continue play is not working correctly.
Prepare list tracks are shown “BLUE” color unexpectedly.
BPM shows “0” in Prepare list.
History is not registered. (this was never resolved even though they say yes)
Title becomes “Empty” when going back from prepare list to title list.
scratching during reverse play in slipmode cancels reverse play.
reverse play is turned off when pressing SLIP button in reverse play.
AAC file recognition issues.
“Key” is not reflected when loading track from HOTLIST.
Yes, I know it was supposed to be fixed. But there are certain forum members who will comment on or criticise anyone even suggesting Denon may have not done something correctly. I’m getting a bit sick of it now and we all (including moderators) know who these people (or person) is.
Bottom line is that the history writing issues have not been fixed. That’s it.
I also did a test using 16 tracks. From my understanding, the track will register in History only after playing a minimum of 60 seconds.
Of the 16 tracks tested, 3 did not register in History. I replayed the tracks and again the same 3 tracks did not register. Apparently there is still a bug, perhaps affected by the build/quality of certain tracks. Looks like more testing needs to be done to determine if this can be resolved.
Other than that, I’m happy with the stability as my MCX since the last update.
I wondered that too. It would be nice if the three tracks that didn’t register in the history were all WAV for example, and all the tracks that registered were MP3, as that would be easy to spot.
It might be something more deep though, like those with saved memo cue points and those without, or those that were analysed or not. Maybe it’s even things that happened during the playback, like if searching was performed then the history file didn’t get updated for the song that was playing during the search, or if the search was started before or after that “track must play for 60 seconds for that track to get added to history.”
It would be nice if inmusic could fix it though as one last update for this quite established model.
The more I think about it, the more I think it’s a pen drive “Busy” thing, rather than the playing files themselves.
Maybe the history file gets written to at 61 seconds, as we know that the file has to play for 60 seconds before it’s considered “played”. So what if the file system is already doing something at 61 seconds? Like searching or saving cue points? Maybe the mcx 8000 needs to check a minute later to see if the file got added to the history list, or not, and add it if it didn’t. All guesses , but there’s got to be some pattern to it.
I took part in the beta and posted this issue. I even shared a few example tracks with the beta team. I was told that it was corrected and for me to provide feedback. Unfortunately I didn’t get the opportunity to verify the on my end (as you know, beta testing is completely volunteer). I’m assuming that they considered it fixed since they didn’t receive a response from me and no other testers reported it as an issue.
Guess I should’ve followed up… Ooops!
If it hasn’t already, it should resubmitted as a Bug.
At this stage, we are not bringing new features to the MCX8000. If there are serious issues that prevent the use of the product we will investigate but otherwise, the product will not likely see new firmware updates. I hate to be the bearer of bad news here but I wanted to provide some clarity on this thread.
To be fair, the MCX8000 saw a number of significant updates over the last few years and still continues to service the DJ community quite well. We hope you continue to enjoy the product especially with the new SoundSwitch functionality we recently added.
@JWiLL We do appreciate everything that has been done, it’s an excellent piece of kit. But it would be appreciated if you can investigate the bug with not writing to history. This has been an issue for some time now.
If you need external help with investigation please let me know.
Hi @kradcliffe - It’s a great sounding board and still one of the most versatile all-in-one units today. I used it myself for many years as a mobile event DJ.
Honestly, we were under the impression that 2.5 resolved that particular issue as it was not brought up again by our beta team with the RC build but sadly it seems to still be problematic.
I appreciate the offer. If we had solid reproduction steps and could easily reproduce in our environment it would certainly help but please understand I can’t make any promises that it will be addressed.
I have noticed some of the situations under which this occurs and I published it in the link mentioned by @JWiLL , the only thing I need to verify is that it is a problem with some specific memories at the time of writing in them I already know from their speed or something else, I also offer myself to help as much as I can, at some point I suggested the release of the source code as open software, but now that engine is depreciated in favor of engine os, although I do not know how much code they share that would do this Not feasible for now, it is true that it is a very good team, the only thing that stained its reputation a bit were the units with the screen problem and some problem in the firmware like the one we talk about here that for some it can be annoying, without these two things even today if I had to choose between esat and a prime I would choose the mcx8000 for the mere fact of the quick change between serato and autonomous mode which is mutually useful for the dj change, I hope this feature Stica is available soon in some prime meanwhile faithful to my mcx8000