Zap timer causes UI hang when multiple bouquets disabled

[prl]

If you disable MENU>Setup>TV>Channel selection>Enable multiple bouquets, and a zap timer starts, the UI hangs. It shows the spinner, doesn't respond to remote or front panel and "init 4" in the command-line can't restart it. "Kill -9" and "reboot" on the command line can recover it without a hard power down. While hung, the enigma2 process shows 100% CPU use, so it looks like an infinite loop. It appears to be caused by similar coding problems to those that caused Bug #454: Using live TV panic button can cause a crash was fixed (that bug was in different code that was also searching the bouquets for a service).

This issue is in the same code as Bug #475.

Replication steps

Disable MENU>Setup>TV>Channel selection>Enable multiple bouquets.

Create a zap timer that will trigger in a short time.

When the timer starts, the UI hangs and the spinner appears. Use top on the commandline to verify that enigma2 is using 100% CPU time.

Recover using

killall -KILL enigma2

on the commandline.

[prl]

This bug also applies to "zap and record" timers (the "zap" part of the code for that seems to be a copy/paste of the code for "zap" recordings).

[Peter Urbanec]

Fix Bug #474: Zap timer causes UI hang when multiple bouquets disabled

[RecordTimerEntry]

In _zapToTimerService():

Move the search through the bouquets into the "true" side of the if test on config.usage.multibouquet, and add code to search the Favourites list only in the "false" side of the test.

This means that "zap" and "zap and record" timers now both no longer hang the UI (previous commit) and function correctly (this commit).

Only do a ChannelSelectionInstance.enterPath() on one bouquet when config.usage.multibouquet is disabled, so that the title on the channel list is displayed correctyl. Move the ChannelSelectionInstance.clearPath() to immediately before the enterPath() calls to bring all the path list operations together.

Use a predefined base eServiceRef to define the multi-bouquet root serviceref. This must have been missed when the serviceref cleanup was done.

→ <<cset 76f4d1283139>>