VTDJ role not able to record voicetracks?

But someone voicetracking must be allowed to add items – otherwise he weren’t able to insert the takes he had just been voicetracking. Maybe the voicetracking feature should be limited upon playlist level only?

That was indeed what I was thinking of.
Besides adding items, moving items is also neccesairy for voicetracking. Only moving items is now only done on API level and not possible in GUI level.
It would be great if ‘adding items’ also will be disabled in GUI level for VTDJ role.

Are you really sure? Here’s a screenshot of my system, logged in as a VTDJ user - all grayed out:

Bildschirmfoto von Parallels Desktop (07-07-22, 15-55-36)

And now it gets strange, very strange,

I have 2 radio stations under my care. my hobby radio station and a local radio station.

After installing build 5034 on all systems, both systems respond differently.

at my hobby radio station it works indeed that a vtdj cannot add/import files. the message appears that at least one ‘folder manager’ role is required:


at the local radio station (where really all settings are identical and the remote pc is the same pc/instance as where I test my hobby radio station) someone with a vtdj role can add / import files:


I have already installed build 5034 on the server several times (also run the installation as administrator) but the problem remains as shown here:

Now I have discovered this:
if the vtdj user is tested within a lan connection in the studio (using a sql database connection), then that person cannot add/import files.
As soon as a connection is made via the dbserver over the internet (with a DB Server internet client as database setup), the person concerned can add/import. This also applies if such a connection is realized within the LAN.

How strange is it that it seems to work on my own station, but not on the local radio station?

I have created new ser and key files using ssl buddy software. but no difference

The DB server connection ensures that the restriction lapses… but why with one and not the other?
I compared the dbserver settings in programdata folfer and found no differences. so it’s not here either. but where??

If you want, I’ve created users for Torben for both servers to test and see that somehow it isn’t functioning well (both an admin and a vtdj role for each station)

I just really don’t know what this could be.
As said… mairlist build 5034 has been reinstalled at least 10 times…

Thanks for the test accounts. I was able to reproduce and identify the problem. It should be fixed in Build 5035 now. You must only update the client side.

1 Like

Has anyone ever told you that you are really good? Bizarre how quickly you occasionally find and especially solve those bugs. respect!

Now it may be pure curiosity, but what caused it to work on 1 station and not the other? I seriously thought I was going crazy while testing this glitch.

You recommend running only the client on Build 5035 and keep the server on 5034? or would it hurt if the server eventually also goes to build 5035?

I will probably install and test build 5035 tomorrow or Sunday…

3 Likes

Well, the more precise the reports, the easier it gets. So thank you for the good collaboration!

The bug was definitely the DBClient connection, not retrieving the actual permissions/level, but always pretending to have admin permissions (when it comes to enabled/disabled GUI functions). No idea why it didn’t happen with the other connection :man_shrugging:

Only the client was affected, the server code remains the same.

I have just uploaded version 7.0.2 (which is build 5036). This will probably the last update before August.

1 Like