Repeated Timer filenames are corrupted

[felixalacampagne]

https://github.com/OpenPLi/enigma2/blame/81e8a636c04f0ef69ef341332830c6c00ed4c949/lib/python/RecordTimer.py#L342

Just switched to using an Octagon SF8008 receiver running OpenPLi 9.0 instead of a Dreambox DM7025 also running OpenPLi (not 9.0!) and have seen that repeated timers are being saved with corrupted filenames, eg.

Timer title/name: Showname YY-MM-DD 1x01 Episode 01
Expected 'standard' filename: Timerdate - Channel Id - Showname YY-MM-DD 1x01 Episode 01
Actual filename: Timerdate - Channel Id - Showname

Note that my VU+ Ultimo with OpenPli saves timers with the expected 'standard' name.

After some searching I tracked this down to some code in RecordTimer.py which, for no discernible reason, is replacing the required filename with the 'eventname':

L342: name = event_name
if not self.calculateFilename(event_name):

I have fixed this for my current installation but I imagine that my fix will eventually be overwritten by updates which will unexpectedly cause the corrupted filenames to start appearing again, and causing me to waste a lot of time fixing the filenames.

So, is there any way to get this fix included the release code?
Or some option added to restore the normal behaviour for filenames if for some inexplicable reason the current behaviour is desirable.

Also, how can I tell which branch was used to create the installed version? I originally tried updating the 'develop' branch version that completely broke the UI. I had more success with the version from 'release-9.0'. The version of openpli installed is reported as 'OpenPLi 9.0-release (2024-10-11-release-9.0)' but the release-9.0 branch seems to be much older.

[littlesat]

Please post the changed you suggested (preferable in a merge request)

[WanWizard]

I don't see any evidence of "corruption" in your report.

Just that you observed a change of filename generated for a recording, which is caused by you comparing an old release to a current release, which has options (expert settings, record) to define what kind of filename you want.

What you describe looks like it is set to "event" instead of "standard".

See https://github.com/OpenPLi/enigma2/blob/develop/lib/python/RecordTimer.py#L236

[felixalacampagne]

Sorry - this is the first time I've been moved to make such a post on github and I don't see how to reply to specific posts...

@littlesat: Please post the changed you suggested (preferable in a merge request)
I think my 'fix' would be unacceptable since it involves simply setting the 'repeated_rename' flag to False - I can't actually find anywhere that it is ever set so I guess the default value of True in RecordTimerEntry.init parameter list always applies.

@WanWizard: I don't see any evidence of "corruption" in your report.
The file name is corrupted in that it does not contain the text that I provided for the name. If the timer is not a 'repeated' timer then the filename is as expected. The time filename mode is set to 'standard'. The name is being corrupted before the call to calculateFilename when the required name is overwritten by the program name at L343.

When I initially logged the issue I hadn't realised that L343 was part of a larger block for processing of the 'repeated_rename' flag. So the corruption of the filename appears to be deliberate, if unwanted.

My original request for an option to restore the normal behaviour is still valid.

[WanWizard]

Whether or not it is a repeated recording, fact remains you can select in the recording configuration what the format of the "calculated filename" should be.

So the options are

		filename = begin_date + " - " + service_name
		if name:
			if config.recording.filename_composition.value == "event":
				filename = name + ' - ' + begin_date + "_" + service_name
			elif config.recording.filename_composition.value == "short":
				filename = strftime("%Y%m%d", localtime(self.begin)) + " - " + name
			elif config.recording.filename_composition.value == "long":
				filename += " - " + name + " - " + self.description
			else:
				filename += " - " + name # standard

where name contains what you call "timer name".

Which implies that

Timer title/name: Showname YY-MM-DD 1x01 Episode 01
Expected 'standard' filename: Timerdate - Channel Id - Showname YY-MM-DD 1x01 Episode 01

equals the "standard" selection, which is begin_date + " - " + service_name + " - " + name , like I already wrote.

[felixalacampagne]

@WanWizard: As you will have noticed when you read the code around L342 the 'name' value is overwritten with the event name, ie. 'name' has already been corrupted when the code you are referring to is called.
The code in question:

   name = event_name
   if not self.calculateFilename(event_name):

This code is part of a block of code executed when flag 'repeat_rename' is True.

I have found no way to configure 'repeat_rename' and the default appears to be True.

[WanWizard]

I've asked if one of the developers can have a look at it.

[Dima73]

felixalacampagne
Maybe simple set "Rename name and description for new events" -->"no" for this timer?

[littlesat]

Yes that was intended because especially for repeated timers the event can change to eg a different series.
And the recording is better named with the correct event at that moment instead of the event name at the moment the repeated timer was programmed.
Adding an extra config for this is something I do not recommend as we already have a lot of Tiny configs there. Having the name according the real event is I think more logical.

[felixalacampagne]

Took me a while to find "Rename name and description for new events" since it only appears in the TV UI when a timer is set to be repeated. When a timer is created it appears that the default is to enable this new and annoying behaviour. I could almost understand it being the default if the 'event name' mode of setting the filename was selected but having the name chosen by the user automatically overwritten by default definitely does not seem logical to me.

the recording is better named with the correct event at that moment instead of the event name at the moment the repeated timer was programmed.

I disagree with this as I would far rather know what I was expecting to have recorded, ie. use the name I originally entered for the timer, rather than see a surprise unwanted recording with possibly no reference as to why it was set to be recorded.

I usually set timers via OpenWebIf and this setting doesn't even show up in the timer details, hence my surprise that the values I am providing for the filename are being corrupted.

I've checked the source for OpenATV and it appears to have a similar setting so I guess I will just have to accept that this is here to stay and pay attention to restore my fix when the software gets updated or hope that OpenWebIf eventually provides a way to override the default setting.

[Dima73]

"Rename name and description for new events" in create new timer default 'no'.

[felixalacampagne]

"Rename name and description for new events" in create new timer default 'no'.

This would certainly make me happy. Unfortunately the default is currently ‘yes’.