Creating an Autotimer for a program < 1 hour after Midnight from Guide uses previous day as Filter.

[dRdoS7]

Hi,

I was creating some Autotimers for my wife on my T2. When I pressed BLUE while in the Guide to create one for "Chance" on SBS HD (Tuesday 00:30), it showed "Monday", instead of "Tuesday". I didn't notice that at the time (I just press GREEN, and then edit in the "Edit AutoTimer" screen). When I checked the Timer list, there was no timer for "Chance". I went into AutoTimers, there was one for "Chance", but the day was restricted to "Mon". I changed "Monday" to "Tuesday", and the timer was set OK.

I tested by setting auto timers for several other programs around that time, and it appears to occur if the program starts less than 1 hour after midnight.

Also, is it necessary to have a confirmation if RED is pressed to cancel the creation of an Autotimer from the Guide at the first screen? The first screen is called "Import AutoTimer", "Create AutoTimer" would be more accurate. There's no confirmation if RED is pressed in the "Edit AutoTimer" screen, unless there has been an edit.

Thanks,

dRdoS7

[Grumpy_Geoff]

That is not a bug. The wizard's Match Timespan (start) time is a window extending 1 hour either side of the EPG entry's start/finish times.
For me Chance is scheduled for Tue 00:33-01:26, so the wizard correctly puts the start window at Mon 23:33-Tue 02:26.

[prl]

I agree that the "Import AutoTimer" title is a bit odd, but the AutoTimer code explicitly overrides whatever the skin specifies as the title. The intention is "Import timer settings from EPG", but it's probably not what I'd have chosen, and probably should leave the skin designer's title as-is.

[dRdoS7]

Hi,

That is not a bug. The wizard's Match Timespan (start) time is a window extending 1 hour either side of the EPG entry's start/finish times.
For me Chance is scheduled for Tue 00:33-01:26, so the wizard correctly puts the start window at Mon 23:33-Tue 02:26.

It didn't create a timer for me. Did it create one for you? When I changed Monday to Tuesday it created a timer.

dRdoS7

[Grumpy_Geoff]

Hi,

That is not a bug. The wizard's Match Timespan (start) time is a window extending 1 hour either side of the EPG entry's start/finish times.
For me Chance is scheduled for Tue 00:33-01:26, so the wizard correctly puts the start window at Mon 23:33-Tue 02:26.

It didn't create a timer for me. Did it create one for you? When I changed Monday to Tuesday it created a timer.

dRdoS7

Apologies, I didn't have that quite right in my reply.
I should have said -
For me Chance is scheduled for Tue 00:33-01:26, so the wizard correctly puts the start window at between 23:33-02:26.
The wizard incorrectly sets the day filter to match the Monday start window. So, yes - appears to be a bug.

Knowing that Chance is shown weekly, I would untick the Match Timespan, and Only on Weekday requirements.
I have the plugin defaulting to the Favourites bouquet, so I'd untick the Only on Service requirement in any case.

But usually I wouldn't do it that way at all, I'd just use OWIF to create the Autotimer

[dRdoS7]

Hi,

The wizard incorrectly sets the day filter to match the Monday start window. So, yes - appears to be a bug.

OK.

Knowing that Chance is shown weekly, I would untick the Match Timespan, and Only on Weekday requirements.

Might end up with a heap of "Cloudy, with a Chance of Meatballs" as well!

But usually I wouldn't do it that way at all, I'd just use OWIF to create the Autotimer

I use the T2. Rarely use OWIF (the Guide display sucks). I do use it to turn on "Logs" though. Wonder if that could be done with a script?.

My wife handed me a list of programs (Day, Name & Time) she wanted me to record on my T2 while we're away, easy to do from the Guide. Normally if we're away for only a short time she'd record on her T2 at home, but after last year's U4 HDMI output failure, she insisted we now take her T2 as a spare DVR when we go away in the 'van. Toasters & Kettles are easy to replace, DVRs, not so. At least one of those will fail in the year.

Thanks,

dRdoS7

[prl]

Rarely use OWIF (the Guide display sucks). I do use it to turn on "Logs" though. Wonder if that could be done with a script?.

Something like:

Code: Select all

init 4
sleep 2 # Allow some time for the UI to shut down and write /etc/enigma2/settings
grep -q 'config\.crash\.enabledebug' /etc/enigma2/settings || echo config.crash.enabledebug=True >> /etc/enigma2/settings
# add next line to set the crash file location to /media/hdd/logs
grep -q 'config\.crash\.debug_path' /etc/enigma2/settings || echo config.crash.debug_path=/media/hdd/logs >> /etc/enigma2/settings
init 3

NB: The script is untested, and doesn't check whether there are any recordings, tasks or playback being done when it shuts down the PVR application (the init 4 command).

However, log file settings are saved in a settings backup, so you shouldn't have to do this sort of setup very often. I'm not sure it's worth making a script for.

[Grumpy_Geoff]

Rarely use OWIF (the Guide display sucks). I do use it to turn on "Logs" though. Wonder if that could be done with a script?.

Something like:

Code: Select all

init 4
sleep 2 # Allow some time for the UI to shut down and write /etc/enigma2/settings
grep -q 'config\.crash\.enabledebug' /etc/enigma2/settings || echo config.crash.enabledebug=True >> /etc/enigma2/settings
# add next line to set the crash file location to /media/hdd/logs
grep -q 'config\.crash\.debug_path' /etc/enigma2/settings || echo config.crash.debug_path=/media/hdd/logs >> /etc/enigma2/settings
init 3

My experience (dated now, though) is that one has to actually reboot to have the debug log sent to a new location, else the log is sent to /home/root/logs/.
I know MrQuade has had similar experience in the past.

[prl]

My experience (dated now, though) is that one has to actually reboot to have the debug log sent to a new location, else the log is sent to /home/root/logs/.
I know MrQuade has had similar experience in the past.

Not any more (20190207). I don't think it's been the case for some time.

I just tested it: started with logging enabled and directed to /media/hdd/logs, disabled logging and reset it to /home/root/logs/, restarted GUI, no log. Enabled logging and directed it to /media/hdd/logs, restarted GUI, logging as expected.

[Grumpy_Geoff]

My experience (dated now, though) is that one has to actually reboot to have the debug log sent to a new location, else the log is sent to /home/root/logs/.
I know MrQuade has had similar experience in the past.

Not any more (20190207). I don't think it's been the case for some time.

I just tested it: started with logging enabled and directed to /media/hdd/logs, disabled logging and reset it to /home/root/logs/, restarted GUI, no log. Enabled logging and directed it to /media/hdd/logs, restarted GUI, logging as expected.

Okay. When you get a chance, can you try it logging to a directory that doesn't yet exist.

[Grumpy_Geoff]

Knowing that Chance is shown weekly, I would untick the Match Timespan, and Only on Weekday requirements.

Might end up with a heap of "Cloudy, with a Chance of Meatballs" as well!

Not if you use Exact match or a begin match.
You could keep the Match Timespan if you used 'title starts with' search type to prevent stray programs such as 'Chance for the Cats to beat the Maggies' (which they did ).

But usually I wouldn't do it that way at all, I'd just use OWIF to create the Autotimer

I use the T2. Rarely use OWIF (the Guide display sucks). I do use it to turn on "Logs" though. Wonder if that could be done with a script?.

My wife handed me a list of programs (Day, Name & Time) she wanted me to record on my T2 while we're away, easy to do from the Guide.

Yep sure, but each time you saved the AutoTimer definition it would go and parse all of the definitions against the EPG.
If you did the list via OWIF, the parsing would be done on its normal schedule (or when you pressed the 'Parse' button in OWIF) not when each definition was saved.
I know you don't like the EPG display on OWIF, but it is easy to click on the day, search for the title (CTRL-F browser search), click on the event, hit the AT button, edit as needed, Save. Rinse, repeat. This method doesn't have the "day filtering" bug that the wizard has.
Alternatively, just enter them all via the Add button in OWIF's AutoTimer panel.
A lot less button presses than using the remote and the GUI, and a lot quicker.
Each to their own.

[dRdoS7]

Hi,

Just had a look: my log is dated from 2019-02-28 and is 21MB.

My settings:

BW Logs.jpg (37.59 KiB) Viewed 2412 times

Seems not to be obeying those.

Also, it won't open on the T2, but I can open it via WinSCP.

I'll put that script on the T2s. I'll write one to disable as well.

Code: Select all

init 4
sleep 2 # Allow some time for the UI to shut down and write /etc/enigma2/settings
grep -q 'config\.crash\.enabledebug' /etc/enigma2/settings || echo config.crash.enabledebug=False >> /etc/enigma2/settings
init 3

??

Thanks,

dRdoS7

[Grumpy_Geoff]

Hi,

Just had a look: my log is dated from 2019-02-28 and is 21MB.

My settings:

BW Logs.jpg


Seems not to be obeying those.

It's long been known that the log limits aren't obeyed - the last report on this from prl was that the cleanup code is there but nothing executes it.

Also, it won't open on the T2, but I can open it via WinSCP.

It should open in File Commander, press TEXT on the file.

I'll put that script on the T2s. I'll write one to disable as well.

Code: Select all

init 4
sleep 2 # Allow some time for the UI to shut down and write /etc/enigma2/settings
grep -q 'config\.crash\.enabledebug' /etc/enigma2/settings || echo config.crash.enabledebug=False >> /etc/enigma2/settings
init 3

??

I don't think that'd work as the '||' is an "else if the return code is non-zero". Even if you fixed that up, I think you'd end up with an enabled-true and multiple enabled-false lines every time the disable script was run. I think you'd need to remove the 'config.crash.enabledebug=True' line from the file. Using something like a sed or an awk or a grep -v that prints out every line that isn't 'config.crash.enabledebug=True'.
This might work cat /etc/enigma2/settings | grep -v 'config.crash.enabledebug=True' > /etc/enigma2/settings

[prl]

My experience (dated now, though) is that one has to actually reboot to have the debug log sent to a new location, else the log is sent to /home/root/logs/.
I know MrQuade has had similar experience in the past.

Not any more (20190207). I don't think it's been the case for some time.

I just tested it: started with logging enabled and directed to /media/hdd/logs, disabled logging and reset it to /home/root/logs/, restarted GUI, no log. Enabled logging and directed it to /media/hdd/logs, restarted GUI, logging as expected.

Okay. When you get a chance, can you try it logging to a directory that doesn't yet exist.

OK, tried that. If the logging directory doesn't exist, restarting the GUI results in the new log going to /home/root/logs. But it's the exactly same for a reboot.

What does work if the log directory doesn't exist when logging is enabled is to do either a reboot or a GUI restart twice (in any combination). What's important, though, is that the GUI is started twice, somehow.

The cause is left as an exercise for the reader.

[Grumpy_Geoff]

What does work if the log directory doesn't exist when logging is enabled is to do either a reboot or a GUI restart twice (in any combination). What's important, though, is that the GUI is started twice, somehow.

Okay, so the GUI starting twice is what I've/we've observed. Now we know

The cause is left as an exercise for the reader.

I'm not smart enough, I've looked at it a number of times

Code: Select all

# set the debug log file path if debug logging is enabled
# Test for debug logging being enabled using [ -n "${debug_path}" ]
if grep -qi 'config.crash.enabledebug=true' ${sysconfdir}/enigma2/settings; then
        debug_dir=$(sed -n 's/config.crash.debug_path=//p' ${sysconfdir}/enigma2/settings)
        [ -n "${debug_dir}" -a -d "${debug_dir}" ] || debug_dir=/home/root/logs/
        debug_path="${debug_dir}Enigma2-$(date +%Y-%m-%d_%H-%M-%S).log"
fi
...
if [ -n "${debug_path}" ]; then
        LD_PRELOAD=$LIBS ${bindir}/enigma2 &> ${debug_path}
else
        LD_PRELOAD=$LIBS ${bindir}/enigma2
fi

My guess is I see there's no mkdir for ${debug_dir}, so on the first debug execution the output is sent to /home/root/logs/ because -d "${debug_dir}" fails.
The UI then starts and sees the config.crash.debug_path value doesn't exist and creates it.
Upon any subsequent UI start, the debug directory does exist so the shell script sends it there.

How'd I go?

[prl]

My guess is I see there's no mkdir for ${debug_dir}, so on the first debug execution the output is sent to /home/root/logs/ because -d "${debug_dir}" fails.
The UI then starts and sees the config.crash.debug_path value doesn't exist and creates it.
Upon any subsequent UI start, the debug directory does exist so the shell script sends it there.

How'd I go?

That pretty much nailed it. The directory is created during the enigma2 (UI) starup in Components.UsageConfig:

Code: Select all

	config.crash.debug_path = ConfigSelection(default="/home/root/logs/", choices=debugpath)

	def updatedebug_path(configElement):
		if not os.path.exists(config.crash.debug_path.value):
			os.mkdir(config.crash.debug_path.value, 0755)

	config.crash.debug_path.addNotifier(updatedebug_path, immediate_feedback=False)

updatedebug_path() gets called by the notifier mechanism if config.crash.debug_path is assigned a non-default value when /etc/enigma2/settings is loaded. But by then, it's too late, because the decision to log to /home/root/logs has already been taken in enigma2.sh.

[dRdoS7]

Hi,

Maybe a couple of new settings in the Menu would be better? IE.: Debug Log - On/Off, and location - "/root/home/logs" as default. Preferably, it shouldn't require a Reboot.

dRdoS7

[prl]

Maybe a couple of new settings in the Menu would be better? IE.: Debug Log - On/Off, and location - "/root/home/logs" as default. Preferably, it shouldn't require a Reboot.

It wouldn't be hard to add the settings to the setup screens.

However, that wouldn't change the need to restart the GUI. A reboot is never necessary to change the debug logging, though you can do it that way if you prefer. The main hitch happens if you change the logging to somewhere there's no logs directory already. Then you need to restart the GUI twice to get the logging to go the right place. Any normal means you like will work, provided the GUI gets restarted twice. You can just restart the GUI twice, reboot twice, or do init 4 then init 3 on the command like, or any combination that results in the GUI doing a clean shutdown and a normal restart twice.

Logging would need to be done in a different way than it is currently done to avoid the need to restart the GUI.

How often do you need to turn it on or off?

[adoxa]

I use the T2. Rarely use OWIF (the Guide display sucks). I do use it to turn on "Logs" though. Wonder if that could be done with a script?.

When I want to enable logging, I run a script to replace /usr/bin/enigma2.sh with a debug version (sets debug_path directly), then just restart. I've also made a patch to increase the in-memory log to 512KiB, which the PIP key will save, so I don't usually need logging on.

[adoxa]

Maybe a couple of new settings in the Menu would be better? IE.: Debug Log - On/Off, and location - "/root/home/logs" as default. Preferably, it shouldn't require a Reboot.

Turns out there was already code in place for this, but it never made it to the menu - you'll now* find "Log settings" under "System" in the Menu (*V2 users should have it in the next beta; might be a few months before others see it). Due to the way logging is handled it does require a restart, but not a reboot.

[prl]

Maybe a couple of new settings in the Menu would be better? IE.: Debug Log - On/Off, and location - "/root/home/logs" as default. Preferably, it shouldn't require a Reboot.

Turns out there was already code in place for this, but it never made it to the menu - you'll now* find "Log settings" under "System" in the Menu (*V2 users should have it in the next beta; might be a few months before others see it). Due to the way logging is handled it does require a restart, but not a reboot.

Does the code create a logs directory if you change the log location and there's no logs subdirectory there? If not, you'll need two restarts (or reboots) to enable logging if you change the log location.

[adoxa]

Does the code create a logs directory if you change the log location and there's no logs subdirectory there? [...]

Yes, I fixed that, too.

[prl]