I'm trying to create a service through automation script for a particular Titan decoder, lets say decoder-5, for the table Decoder Program. In original titan device I can see 3 rows already present in that table (decider 5, 6, 9 shown below).
After the service is created i can see only one row(decoder 9).
while comparing decoder 9 with 5 and 6, found the difference that the primary key value has whitespace at the end for decoder 5&6 and for decoder 9 it is not there.
From automation script I have verified the extra whitespace is not trimmed. It is getting trimmed in engine.AddService(serviceInfo, viewIds) while adding the service to Dataminer.
This must be the case for all the cases, if there is whitespace at the end of the primary key or display key it will be trimmed on service creation from automation script.
Kindly confirm is this the issue or there must be some other reason for not getting decoder-5&6 in my service.
while adding service name in Decoder program table, operators are adding whitespace at the end sometimes, while saving it whitespace is left as it is i assume. Which is creating the issue i have mentioned.
yes please, would like to hear from you about actual cause
Hi Baranisudha,
I believe you're correct - as names in DM cannot start or end with a space:
this can be verified when adding an element or a service
if that's what's affecting your script, you may find evidence in the info events or in the stack when your automation runs and only one service is created, instead of the three defined in the table.
To be honest, trailing spaces are never a good idea when it comes to naming - but maybe they are allowed by the source encoder creating the PSI/SI and the decoder is simply reading that "service name" in the SDT.
If editing the SDT to remove the "bad space" (at TS level) is not a possibility, you may have to tweak the automation to perhaps parse the name in the table (e.g. if a space is found --> convert to an underscore)
HTH
"Service Name" is the table column in Decoder Program table in titan device.
The table data are not created in dataminer. Operator is assigning a event to the element and based on the configuration of that particular event that is provided in titan Dataminer is populated with data. I guess leaving a space at the end while configuring is a mistake. If titan is allowing a space at the end while configuration, dataminer should trim while populating the data itself. But data is populated with whitespace and the trimmed while creating the service with Decoder Program table.
Operators can't be in caution to not use whitespace as they are non-technical. We should handle it from our end i guess.
Yes – I was thinking this might come from the name entered in the Transport Stream itself – if the end device allows the space, the automation will have to account for that, hence the suggestion to parse the names before creating DM services.
Is the space required at the end of the name?
I'd check with the team managing the Titan decoder (or perhaps the source encoder) – normally, in DM, names should not start or end with spaces – may be able to share more info in a bit