Traktor Pro 3.8 still has flashing browser when you load tracks

wayfinder

https://community.native-instruments.com/discussion/comment/55292#Comment_55292

just as an aside, I would love to have #-descending, but NI doesn't allow that for some reason

Sûlherokhh

https://community.native-instruments.com/discussion/comment/55709#Comment_55709

Yes. I started missing that feature the day i started using Traktor Pro for the first time.

[Deleted User]

The user and all related content has been deleted.

Kubrak

@Sûlherokhh

just as an aside, I would love to have #-descending, but NI doesn't allow that for some reason

I agree, that it is strange that NI does not allow to sort by # in descending order. I do miss it as well....

[Deleted User]

The user and all related content has been deleted.

Oxy

The faster your computer the less flickering you will see.

On my i9 12900k it's basically non existent.

mainTAP

On a mid-2011 Mac mini is the flickering quite noticeable

SteveKDJ

https://community.native-instruments.com/discussion/comment/56244#Comment_56244

Is this now considered bragging? :)

not everyone can afford the expensive processor and configuration.

It doesn't blink for you, be happy about it. it also blink when analyzing numbers, loading numbers, no matter what I set. So that's my problem, and I'm really annoyed by this kind of flashing. 

Thanks

T_G

Whatever the assumptions here on "wrong" use or bug/not bug because it is not happening everywhere... The definition of a bug that is not that it has to occur everywhere. And this thing is surely buggy as hell, meaning the browser.

In my case, with 102k tracks and 4TB of storage this works like a charm without any flickering at all. Until I put something in the search field. Then the browser starts flickering like hell and sometimes it is away for seconds!!! I am developing SW since I am 6 years old, this was in the 80ies, since the 90s professionally. If I read that some DBs are simply too big this costs me a laugh.

I don't get personal, but are you like joking or what? My collection is 135MB, no matter what you sort or do in there is not even recognizable for you brain normally. Some people do like we are talking about GB or TB of databases here. This is just laughable. It just takes only measurable time to sort 102000 datasets, but no human noticeable lag of seconds

The collection is stored on a 970 Evo Pro, away from the fact that a whole collection, until it is maybe 1GB big should be kept in RAM at all times during operation of Traktor.

If I enter something in search field and enable inline editing in the preferences a 6 core i7 running at 4.1 GHz comes to a halt of 4-5 seconds before the browser screen comes back... 😉

If I disable inline editing this issue does not occur and the browser is really quick as expected for instance.

Please NI, this needs a whole rework and if you need any further professional analysis assistance when things happen please let me know. And hopefully this can get sorted for the future.

We do not need fancy extensions if the core does not work properly,

Thanks

Kubrak

I am not defending NI, but what you describe is not a bug. It is behaviour. Not optimal function is not bug, it is behaviour. It does not behave wrongly, it is just toooo sloooow.

The flickering described is not a bug as well. It is behaviour. NI has decided to show user the warning that sorting will take some time... It make the flickering on decently fast systems, but is appropriete on slow ones. The solution might be that text is shown only on slower systems....

You are right that things could be made better, or even much better. I guess, programmers do not test it for 100k tracks. I do not know if it is typical use case. By the way, it would cost about 100k USD to buy such an amount of tracks.... And it would take almost one year day and night to listen to it at least once.

But still, you are right, it should be programmed with better care....

T_G

Are you joking? Users with literally 50 tracks in their collection experience this behavior.

I perfectly explained above that it is impossible that it is that slow without a buggy implementation behind it. Please feel free to name it what you want. The implementation is buggy.

No proper sort in these ranges takes this amount of time. The flickering is not only caused by the/a warning message.

Just enabling a preference without actually using it but using the browser same way as without the preference set speaks for a buggy implementation, because nothing in the usage changes. You do not even need to click onto an inline editable field. It is just the setting. So, buggy.

They do not need to test for 100k tracks, because people with much less tracks experience such issues. Althoug they should test for 100k+ tracks. I also explained that there is no reason that there is ANY lag with this small amount of entries. 100k is nothing from an IT standpoint. We are talking IT small, I don't care how much 100k tracks are for you.

And thanks for showing your math skills and interest in money. What exactly do you want to tell me with that statement?

Kubrak

Why should NI think about testing 100k tracks' database? As I explained you such a big library of tracks would cost about 100k USD and would take almost one year to listen to it at least once. It does not seem to be typical user use case.

I have not been able to reproduce any flickering problems even on relatively slow system (passively cooled 4C i5 "tablet"). And what that video has shown was just "flickering" caused by showing that user warning.

OK, we both have been SW developers for 30+ years... Your and my definition what buggy means is different....

Still I agree with you NI could do those things better and much faster. If they decided to invest human resources (money) into it. As a long time developer you must know, that managers decide, on what the time should be spent, not the programmers. Programmers prefer to make the best code ever and spend years on that holly grail goal.

T_G

Because they optimized the import for DBs bigger than 100k tracks some time ago. This must have had a reason, don't you think?

And if the sorting/searching for something is sub 1sec in a db greater 100k and after I enable inline editing I get black screens for seconds than something is not right. This is not "behavior"

But you know what, you are right because I really have things to do worth the time than discuss what a bug is or how many tracks people are allowed to have after collecting music for more than 3 decades.

Have a nice sunday!

Kubrak

100k tracks in 30 years is roughly one CD a day.... I love music and have collected many, many CDs and LPs. And also downlosded a lot, lot from elsewhere, but I am still very far from 100k. And most of it is not very suitable for dancing, so my Traktor collection is only 2k or so.

I believe you that you need 100k track's database in Traktor, but to me it does not make much sense. But I trust you that it makes sense to you.

I hope for you, NI will improve DB searches, it is doable. I do not need it and will not ever need it. Maybe 20k in several years. And that time' CPUs will handle 20k database even with current Traktor code...

Spazoo

How about NI adds "Fix the browser bug" to their roadmap??? I would really appreciate that.