Bug #2856
closed
Multiuser Profiles silently reject new recording if program already scheduled under different profile
Added by blue note over 10 years ago.
Updated over 10 years ago.
Found in version:
4.1.5~gea70c10
Description
Trying to schedule a recording that already exists under another profile silently fails.
To recreate:
Log in as profile 'bsmt' , schedule a recording
Log in as profile 'coach', try to schedule same recording (silently fails)
These are my autobuild options: --enable-trace --enable-libffmpeg_static --enable-hdhomerun_static
In debugging, I set these:
Log path: /var/tvheadend.log
debug trace: (checked)
debug subsystems: +all
trace subsystems: +all
For the period of the log, I create a recording with one profile. Then try to create a recording for the same program in another profile. This silently fails. Then I remove the scheduled recording from the first profile.
I've done my best but if my procedure to create the log needs improvement please let me know.
thanks
Files
If I understand the issue correctly - you cannot enter two recordings for one event through the webui using two different user accounts ? The second attempt is not processed (the new recordings entry is not added) ?
From a discussion on IRC, yes, that's exactly it.
If profile A sets a recording, and then profile B sets the same, then the second one is silently rejected.
If profile A subsequently removes the recording, then B can now schedule it, but there's no 'but B wanted it as well so only remove it from A' function.
Now, how you'd handle different profile directories for two simultaneous but independent recordings is interesting...
Jaroslav Kysela wrote:
If I understand the issue correctly - you cannot enter two recordings for one event through the webui using two different user accounts ? The second attempt is not processed (the new recordings entry is not added) ?
Yes this is exactly what happens.
- Status changed from New to Fixed
- % Done changed from 0 to 100
Applied in changeset commit:tvheadend|9c414a07e6e54c8f93719e2b98f9a5dfa379522b.
OK. Fixed in v4.1-11-g9c414a0 .
Jaroslav Kysela wrote:
OK. Fixed in v4.1-11-g9c414a0 .
That was really fast, thank you.
Also available in: Atom
PDF