Type of ad track

[NestorC]

In the properties window of the ad in ADS Schedelur, there is a value "Type" that is: type of the ad track, also the help says: "The type is used for showing warnings in case two or more tracks of the same type are placed side-by-side (or example, two pizza commercials in a row"
Is there a way to edit that table and add or remove values?

 

[djsoft]

You can input anything to the Type field. The list is formed based on the values you enter.

 

[NestorC]

Yes, you can input anything there, but the list is NOT updated!... when you want to input a new track and view the list, no new inputs are there!

 

[NestorC]

I found that those values are saved in the file: adscheduler.ini, but that list is not updated... Is there a tool inside RB to update it?

 

[djsoft]

Yes, you can input anything there, but the list is NOT updated!... when you want to input a new track and view the list, no new inputs are there!

Thank you, looks like a bug - will be fixed in the next update.

 

[NestorC]

We’ve discussed the Ads Type Track several times, and while it’s a very interesting feature, it currently has a drawback. As you mentioned a few chats ago, the user can type whatever they want into the field. It would be much better if free text wasn't allowed, and instead, we had a dedicated table to pre-load and manage the valid ad types.

Right now, operators frequently make typos when entering a track (e.g., typing "piza" instead of "pizza"). This causes the system to treat them as two distinct types, which means they could end up running back-to-back in the same block.

Having an "Edit Type of Ads" option in the menu bar to manage this list would completely solve the issue.

 

[Guillaume]

I agree with NestorC.
The "Type" option is very useful.
However, re-entering the same types for a new profile is redundant.

Proposal:
The current dropdown menu would list all previously saved types* without allowing users to add new ones directly.
If a user types a value that isn't saved, an error message would appear (e.g., "Please select a type from the list").

The only way to add a type would be via a "..." button next to the dropdown menu.
This setup is very similar to how Track Tool handles Genre (Pop, Rock, etc.) and Language.

Regarding Genre and Language in Track Tool, the current dropdown allows users to add values directly.
I propose applying the same restriction here, if possible: allow adding or modifying values only via the "..." button. This would prevent users from adding values directly into the dropdown input field.
This avoids issues like typos: such as entering "Rokc" instead of "Rock".

Regardless of the technical solution, the goal is to ensure consistent and reliable value usage.
I envision an "edit" section for adding and modifying values (perhaps with the option to create presets?), followed by a dropdown menu used solely for selecting a value (potentially after choosing a preset?).

*Displaying every single type could result in an overwhelmingly long list. We should consider whether it’s feasible to create and select presets instead.

 

[djsoft]

Right now, operators frequently make typos when entering a track (e.g., typing "piza" instead of "pizza"). This causes the system to treat them as two distinct types, which means they could end up running back-to-back in the same block.

They don't need to type it, as it's a combo box, they can click the arrow button on the right and select from one of the existing types.

 

[djsoft]

Proposal:
The current dropdown menu would list all previously saved types* without allowing users to add new ones directly.
If a user types a value that isn't saved, an error message would appear (e.g., "Please select a type from the list").

The only way to add a type would be via a "..." button next to the dropdown menu.
This setup is very similar to how Track Tool handles Genre (Pop, Rock, etc.) and Language.

A solution for now would be to educate the operators to select the value from the list instead of typing it directly.

Regarding changing this to fixed list + separate edit, this sounds reasonable, and will be considered for the future versions.