3 mins to renumber 888 tracks, lmao ..... rediculous.
then, as soon as you remove one of the tracks, it jumbles the order up again ....
Just updated to version 1.5.1.8 and everything's working fine!
Thank you Pioneer. I'm a happy camper :)
System: Windows 7 Ultimate, 64 bit (workstation)
System: Windows XP Prof, 32 bit (laptop)
La publicación no admite más comentarios.
3 mins to renumber 888 tracks, lmao ..... rediculous.
then, as soon as you remove one of the tracks, it jumbles the order up again ....
scrub the re-jumbling ..... thats me being a twat, but 3 mins to renumber lol
Hey Urban, Just created a thread about the long renumbering times, You may want to add to that so they see people are having issues
http://forums.pioneerdj.com/entries/20466103-renumber-track-order-so-slow
@UrbanBeatFoundation
Could it be that RB 1.5.1.8 is not optimized for MAC O/S?
Does it make a difference if file format is compressed?
I hope the engineers can shed light to the above questions since I just did a 'renumber test' of 500 random WAVE music tracks. Sorted per BPM and got these:
00:37 = on my Win XP (Intel laptop with 3.4 GHz processor and 4 GB of RAM)
00:32 = on my Win 7 workstation (Intel Quad 2.66 GHz, 8 GB of RAM)
Clearly, something is wrong somewhere . . .
I doubt that its because it is not optimized for osx, I made a thread posted above and 1.4 worked immediately when renumbering yet 1.5 and 1.5.1 take over a minute to to do the same task, Sucks
Sorry. Just to clarify - it's 37 sec (00:00:37) and 32 sec (00:00:32) respectively.
even 37 seconds is still way too long being that 1.4 did this perfectly, sucks when they make newer versions to fix bugs but new ones are created :(
and renumbering doesnt seem to work properly when trying to renumber the tag list
@UBF
Mine doesn't behave like that. As soon as I remove or delete a track(s), the succeeding tracks are renumbered instantaneously.
we are not talking about deleting or removing tracks, Go into a playlist you have of 3-400 tracks, move a couple around and then choose to renumber them, see how long that takes. It will happen with everyone, it's an issue with the software, not a user by user bases
or are you just talking about this part?
"""""""""""then, as soon as you remove one of the tracks, it jumbles the order up again""""""""""
@BriChi
I just did 2 renumbering test scenarous of 500 WAVE tracks on my workstation:
First Scenario:
Two (2) internet instances open/running (I was doing a search for some hardware when I say your posting).
Opened RB with 'Collection' and 'Playlist' displayed
Grab 500 wave tracks, sorted per BPM
Ran the numbering test
Result: 1 min 11 sec to finish
Second Scenario:
Rebooted my workstation
Ran/open RB alone with 'Collection' and 'Playlist' displayed
Grab 500 tracks, sorted per BPM
Did numbering test AGAIN
Result: 25:02 seconds to finish
Then, I tried moving three tracks (from the newly renumbered tracks above) - as you mentioned above
But, each time a 'drop' those 3 tracks anywere within the playlist - the renumbering is instanteneous.
By the way, TAG List accepts a maximum of 100 tracks only.
same here, If I sort by number column and move tracks, the renumbering is instant but if then sort by track, right click and "renumber track order", It literally just took 1 minute and 35 seconds to complete. I had ONLY RB open too, Not that that should matter on a Mac with a i7 processor and 4gb of ram, Plus in 1.4.1 this happens instantly so it is an obvious, reproduceable bug in 1.5 and 1.5.1
So I just made a video, pretty boring but you can see the comparison on 1.5 vs 1.4
just captured a small area to cut down on file size but you will get the point, the playlist contains 400 tracks
1.5.1 open, sorted some tracks based on number column highlighted, tracks instantly change number
sorted by track alphabetically, right click and renumber at 17 seconds into video, the renumbering does not finish until 1:50 into video
closed 1.5.1, opened 1.4.1
did the exact same steps, renumbering was instant all around
Pio, this cannot be any more easier to see and reproduce, Hopefully it will be fixed in the next update, it is really annoying, especially since it maxes out my mac and heats it up really bad for that minute and half
here is the video: http://www.youtube.com/watch?v=j9sFP-AU4tA
you can pretty much FF from 18 seconds to 1:50 being that that's the part the sorting is locking up
I watched your video and pretty much you nailed it by the head - an un-deniable proof!
Don't want to rub it in but if mine was a fluke - all the same, I welcome it.
I may add, that RB is a very processor dependent and also not multi-processor aware.
I hope Pioneer can do something about this tho' I would like to see the DJM 2000 firmware update first before anything else - just my take!
Slightly OT - Given all the issues with RB, I start to wonder whether outsourcing the software part to MixVibes was a really good idea... Given the time that goes between each update and the low quality of resulting products, maybe developing everything in-house would have yielded better results - included for Pioneer's image. Sure, more expensive, but better for Pio's reputation.
agree 100%, I think it was a bad idea being that Mixvibes is not even decent software to begin with, so why start off with crap and try and improve it, just build from scratch or buy from a reputable company like Serato, start with their software and then tweak it so it's compatible in LINK and exports. At this point, I think that's Pio's best route, start over with better programmers dedicated just for the software, They are building all the new lines based on RB yet everyone is bitching about the stability of RB, not good at all. Hopefully we will see a 2.0 with ONLY Pioneers name on it :)
Remember IBM's OS/2 and Windows? IBM hired Bill $ates to do programming of OS/2 operating system. Where is OS/2 now? Abandoned, trashed and forgotten. It's scary to think that history might repeats itself.
I'm pretty happy with it so far, for some reason I don't get a status bar when exporting, but that's no biggy.
I don't have the problem that you're having BriChi but I only have a max of about 60-80 tunes in any of my playlists so I might just be lucky.
Completely agree about MixVibes partnership as well, I've said it plenty of times on this forum, RekordBox feels like a 0.7 or 0.8 release rather than a 1.5 or 1.6 release. I have no idea what their involvement was with it, but it feels to me like there was a nice dinner in it for the Pioneer execs on the night that the contract was signed.
Yeah i agree the progress of RB has not been real good updates take too long and with new bugs. I know everything takes time and money but all this new hardware is designed around RB. Even i had to pay (a reasonable price) for it so the money part was not so much of an issue as long as it was stable and did most things people are asking it to do. I only hope pioneer can resolve the issues with this software in a speedy fashion.
Angus you are correct, with 60-100 tracks the renumbering is fine, it's when you start to get to a couple of hundred tracks in a playlist, then the renumbering crawls
are you guys importing files from itunes or explorer / finder?
if this is the only issue i never use this feature as ill typically export my playlist to external usb hd then order by bpm or artist on the cdj so this isnt going to cause me a issue by the looks of things?!?!
Speaking for myself.
Speaking for myself:
I don't use MP3 nor iTunes so I don't have 'baggages' or extra processes that is normally associated when migrating tracks to RB.
And like you, I have already done my 'house keeping' - sorted my playlist by BPM - and won't do any 'reshuffling' of tracks during the gig. A flash drive back up of the playlist is ever ready for 'emergencies'
But unlike you, I like working on the big screen of the computer :)
There is no way ill be using a computer out on the road to do any more than control my dmx lighting.. my fingers have been burnt on too many occasions!
everything seems to be working just fine on my end. i was thinking some of the crashes with 1.4 was because of Rekordbox, but after updating the firmware on the cdj-2000s to 4.05, the program didn't crash. now, using Rekordbox 1.4.1 with firmware 4.05, i see no problems at all. dragging tracks from playlist to playlist is fine, importing tracks from bridge while linked works, and best of all, i get to SAVE playlists after my shows because of no crashes!!! i did notice some lag on renumbering tracks on playlists with 100 - 400 tracks. the program totally crashed while renumbering a playlist with about 1500 tracks.
@dj_chuckc > The engineers are working on a fix to the renumbering problem.