My studio requires that, in my program log, I provide a count of Australian music content that has been played.

Modifying one of the standard reports to provide that extra data is a real doddle, provided, of course, that the data exists in the database in the first place.

Oops .... it does not.

If a few custom fields could be added to the songlist table in the database, and maybe those custom fields could then be copied to the historylist table as records are added into that table (not necessary, but makes for an easier query at report time) then this sort of information could be very easily provided.

Obviously, provision for these custom fields would need to be added to the Song Information Editor as well so that it may be captured in the first instance.

My thoughts in this are that you should provide a basic infrastructure for perhaps a half dozen custom fields, along with a secondary table to just hold a field reference and a descriptive label for the field so that when it's used in the Song Information editor, it's referred to in a user friendly manner.

I am not sure if this will give you what you want, but if your create a Category for that particular Group and put the Australian music content in that Category then you can do a report for that category. If all the Australian music is already in a single category folder then you can run the report for a category.

I don't think that will quite do it.

The current logs require us to supply the song name, performer, whether it's Australian, and the label, along with a count of the Australian tracks played.

If I'm reading your response correctly, we would need to pull two reports, which I suspect, given that this is public radio staffed by volunteers, might be inclined to cause more than a little bit of confusion amongst some of the people who will be working with the data.

The other issue with your approach is that there is still no field in the database for the country, and thus I would need to manually go through my tracks and assign them to the category.

The Country field does exist within the standard MP3 metadata, and thus it should probably be mirrored in your database, but my thoughts are that a few (assignable) custom fields in the database would give you a very level of flexibility for end users.

Cheers.

We echo the sentiments for custom fields in the database and so add our voice to this old feature request post. Of course, we have added our custom fields to the database; however, it would be great if SAM would have that feature built-in so that custom fields could also be viewed from within SAM, say like in the Song Information Editor, or Playlist Window.

Regards,
AB

It is possible to add fields to the tables in the database, especially if it is mysql
you would have to use a PAL script or PHP to access them.

I think the request is more than just the ability to have custom fields in the database, since that is easily done by anyone. The greater point is to have SAM Broadcaster have that ability built within it so that the custom field may be created from within SAM itself and viewed within SAM. As it stands now, the custom fields we have are not viewable from within SAM. Certainly we can interact with those custom fields through PAL scripting, but it would be even better to have SAM Broadcaster give the option for the creation of custom fields with the ability to view and sort by those fields in the various windows such as Playlist or Song Information Editor.

Regards,
AB