Exporting Play Counts, Ratings & Duplicate Management

Hello everyone,

I’m writing to propose a couple of quality-of-life features after spending days trying to clean up my extensive local library. My main goal was simple: identify physical duplicate tracks (files with 0 play counts) and remove them from my hard drive to save space and avoid clutter.

Before posting, I searched the forums and saw that I’m not alone in wanting better metadata control. I noticed the April 2025 request about “Choosing which metadata to include on CSV export”, the ongoing 2023-2026 thread about “Editing Play Counts”, and older reports about broken paths during exports. I want to unify these requests by explaining the technical roadblock we are hitting and how it affects professional library management.

To achieve my goal of finding unplayed duplicates, I tried to extract my metadata (Play Counts, Star Ratings, and File Paths) to cross-reference them in Mp3tag. Here is the journey and the walls I hit:

1. The Database Attempt: I accessed the database2 SQLite file and mapped the structure (mediaItems, mediaItemUserData, localMediaItemLocations). However, the data is stored in Apple’s Binary Property List (bplist00) format, and the physical file paths are compiled as encrypted NSURL Bookmarks. This makes it impossible to extract a simple CSV using SQL or Python scripts without breaking macOS security protocols.

2. The Smart Playlist & Sandboxing Roadblock: Next, I created a Smart Playlist with the rule “Play Count < 1”. It worked perfectly inside djay Pro! But when I tried to export these tracks to an external tag editor (like Mp3tag), a text editor, or VLC via drag-and-drop, macOS strict sandboxing blocked the file paths. It either drops standard text (Title/Artist) or refuses the drop entirely. Furthermore, the native “Export to CSV” option does not include Play Counts, Ratings, or the actual local file paths.

The Proposal: Since macOS sandboxing and NSURL Bookmarks lock our files and metadata tightly inside the djay Pro ecosystem, I’d like to suggest two features that would greatly help DJs managing large local libraries:

  1. Native Duplicate Management: A built-in tool or Smart Playlist rule to easily identify and delete physical duplicate files directly from the app’s interface.

  2. Advanced Export Options: The ability to export a Playlist or Smart Playlist as a .csv or standard .m3u file that explicitly includes the physical File Path, Play Count, and Star Rating (solving the previous community requests for better CSV exports).

Having access to our own play history and metadata outside the app would be a game-changer for library management.

If you like this idea and would find it useful, please consider leaving a vote/upvote on this post so the development team can see it!

Thanks for reading and for the amazing software.

4 Likes

Thanks for the detailed suggestion @Albert_Maro. I have passed this onto our dev team for consideration. In the meantime, please use the blue Vote button at the top left of this page so we can gauge user demand for this feature. Thanks!

2 Likes

Hi!

Thank you so much for taking the time to read through the post and for passing it on to the development team. I really appreciate your constant support in the community!

I just have to joke about it: a track’s play count must be an absolute state secret for Algoriddim or Apple if it needs to be guarded so heavily inside an encrypted bplist00 format! It almost feels like trying to crack Fort Knox just to see how many times I’ve played a bachata track. :wink:

I know it was a long read, but I hope the technical explanation makes the issue clear enough to gather a lot of votes from other users. Honestly, I firmly believe this shouldn’t even need to be a feature request—having basic access to our own metadata and being able to manage local duplicates should be a standard, out-of-the-box feature for any professional DJ software by now.

Thanks again for advocating for us!

Just a quick, and final, update to show how deep this rabbit hole goes and the extent of the sandboxing, in case anyone else is trying to find a clever workaround. Spoiler: save your time, it’s systematically blocked.

Out of sheer desperation to avoid manually processing 700+ duplicate files, I tried two last-resort methods today:

  1. AppleScript Automation: I wrote a script to automate the Cmd+Shift+R (Show in Finder) action to grab the paths and build an M3U file. It failed because the “Show in Finder” shortcut behaves inconsistently and doesn’t always highlight the physical file, leaving the script blind.

  2. The Apple Music “Trojan Horse”: I figured that since third-party apps are blocked, Apple’s own ecosystem might be allowed. I dragged my “0 Play Count” Smart Playlist from djay Pro directly into a new Apple Music playlist, hoping to export a clean XML/M3U from there.

The result? Apple Music rejected the drag-and-drop with a system error: “Cannot add an item referenced by a URL”.

This is the definitive proof that djay Pro completely obfuscates the physical file (.flac/.mp3). It only hands out internal NSURL Bookmark references, which even Apple’s own native media apps refuse to process as audio files.

We are officially locked out of our own hard drives when it comes to play history. A native “Delete Duplicate/File” button or a proper CSV/M3U export that includes physical paths is the only way forward. Fingers crossed the dev team takes a look at this!

Update: The Keyboard Workaround (A Band-Aid, Not a Solution)

Since we are locked out of exporting paths or using third-party apps, I’ve managed to create a hyper-fast manual workflow using macOS native tools to process my 700+ duplicates.

Let me be absolutely clear: this is not a real solution. It is merely a temporary patch to bypass a fundamental limitation of the software regarding local file management. We still desperately need native duplicate management or proper CSV/M3U exports.

For those in the same boat wanting to avoid dragging and dropping hundreds of files to the trash, here is the concept of the fastest way to do it using just your keyboard:

The Automator Hint: I basically used the native Mac Automator app to create a “Quick Action”. I set it up so it simply moves any selected Finder item to a quarantine folder on my desktop. Then, I assigned a custom keyboard shortcut to this action in the Mac System Settings (e.g., Cmd + \). (If anyone needs the exact steps to build this Automator action, just ask and I’ll share them).

The Workflow in djay Pro: With that shortcut created, you can put your Smart Playlist (Play Count < 1) on one side of the screen and run this loop:

  1. Click the first track in djay Pro and press Cmd + Shift + R (Shows the physical file in Finder).

  2. Press your new Automator hotkey (e.g., Cmd + \) → Moves the file instantly to your quarantine folder without dragging.

  3. Press Cmd + W (Closes the Finder window).

  4. Press the Down Arrow in djay Pro to go to the next track.

Once you get the rhythm, you can process one track per second. Again, this is just a survival tactic for macOS users. I really hope the Algoriddim team takes note of how far we have to go just to clean up our hard drives!

1 Like

You’re welcome @Albert_Maro

Thanks for sharing your keyboard workaround.

These are the two Python libraries that you need to decode the djay Pro database
import plistlib # decode Apple’s Binary Property List (bplist00) format
import urllib.parse # decode Network URL to Local File Path

FWIW - the Python script below uses urllib.parse to convert a djay Pro .csv to a .m3u file. The network URLs in the .csv file, are converted to local file paths. Had plans to flesh this out with a full database select → .m3u file, but have not gotten back to it. (Definitely worth getting back to.)

2 Likes

Okay, everyone, after days of digging into SQLite databases, AppleScript automation, and Apple Music workarounds, I’ve finally found a way to do this. And honestly, it’s both a relief and incredibly frustrating because of how convoluted it is.

First, I need to correct myself: The file path IS exported in the CSV. I initially missed it because it’s completely obfuscated. Instead of a normal physical path, djay Pro exports it as a raw, URL-encoded string (e.g., file://%20/Users/...) buried in column 7. This raw format is useless on its own—you can’t drag it into Mp3tag, and standard media players reject it.

The “Frankenstein” Solution: Thanks to another user in a different thread (massive shoutout to @Michael_Wisniewski), the only way to bypass the macOS sandboxing and get a clean list of files to delete is:

  1. Create a Smart Playlist in djay Pro (Play Count < 1).

  2. Export as CSV.

  3. Run a custom Python script in the Mac Terminal to parse the CSV, strip the file:// headers, decode the %20 spaces, and repackage it into a standard .m3u file.

  4. Drag that .m3u into Mp3tag to finally delete the physical files.

IMPORTANT NOTE: Voting is still OPEN!

While I was able to make some progress thanks to Michael’s script, let me be clear: **this workaround is still insufficient.**Today it happened to me because I needed to filter and locate files by Play Count, but tomorrow this same limitation could disrupt anyone’s workflow.

We are still facing an issue regarding data accessibility and workflow safety. For instance, in a live gig scenario, if I quickly search for a track and accidentally load the “ghost” duplicate instead of the main one, my play history fractures. Furthermore, the fact that we have to resort to Python scripts just to extract our own file paths—while critical data like Play Counts remains hidden from the export—is honestly quite puzzling. We pay an annual subscription for a professional tool, and having straightforward access to our metadata would be incredibly helpful.

Please, don’t let this thread die. Keep voting and sharing this so the dev team realizes we urgently need native Duplicate Management and transparent CSV/XML exports that include all our metadata!

1 Like

Thanks for the additional info

At the risk of sounding like a broken record on this topic, and building on the great clue @Michael_Wisniewski gave us for extracting paths, I wanted to share one last workaround I figured out.

As we already know from this thread and others, Algoriddim hides the Play Count not just in the CSV export, but also in the file metadata itself, making it completely unreadable by any other software. (I’d genuinely love to know the technical or business reason behind this decision, though I suspect getting an official answer is a pipe dream).

However, since they do allow us to export our Session Histories, I wrote a Python script that reads ALL my exported history CSVs, extracts those obfuscated file:// paths, and automatically counts how many times each track has been played across all past sessions.

To fine-tune this even further: since the history logs include the exact date and time, I can tell the script to filter and onlycount plays that happened within a specific timeframe and on specific days (e.g., weekend nights). This is actually amazing because we often use djay Pro during the week just for library management or track prep, and those shouldn’t really count as “live gig plays.”

I essentially reverse-engineered my own Play Count database. It works perfectly.

I think this simply highlights the extreme lengths users have to go to just to manage basic library data. I’ll just leave that reflection here for the dev team!

2 Likes

I will pass this on…

1 Like