SVN 15741, problem stopping recordings from Mythweb (multirec involved)

[simonwalls@…]

Hi, This is the first time I've ever posted a ticket so here goes:

Using SVN15741 on Fedora Core 8 on a Athlon XP-M 32-bit system.

I've started using SVN, after a few months getting used to Mythtv using Mythdora 4. Now using a fresh install of Fedora Core 8 on a formatted HDD (so no old code hanging around). Receivers: Two Hauppage Nova-T's.

I'm in the UK, on DVB-T, and the main reason for trying SVN is the multirec feature. In mythtv-setup I allowed 3 streams per DVB card, so I see 6 encoders on Mythweb's status page.

I wanted to see 'just how many' DVB-T streams I could record simultaneously. I started to set up recordings on Mythweb for programs which were on at that moment, so recordings started immediately. So I started picking them at random without working out which were on each multiplex. I got to four (I think), which puzzled me why I could not get six. Perhaps I had made bad choices since I hadn't tried to pick the same multiplexes. I didn't try to go further to saturate the encoders.

But the issue I'm reporting is that using Mythweb, I could not command the recordings to stop - whichever way I tried. On the Upcoming Recordings page, click the 'Delete' button on the right hand side of the entry in the list. On the programme details page, click the 'Delete' button. Neither of these worked. Didn't try the Delete+Rerecord as that wasn't what I wanted to do. Backend Status still showed it apparently still recording away. The machine is elsewhere in the house, so I couldn't see the HDD lights.

I eventually managed to get recordings to stop by Deleting the mpeg file from the 'Recorded Programs' page. That caused the Backend Status page to update and as I deleted all the mpeg files, the encoders were freed up.

I haven't tried anything from the front end, just from Mythweb.

So this is a problem, as although I could stop the recordings, if I had wanted to view the programs, I couldn't as I'd just deleted the mpeg files...

Perhaps the multirec merge has caused a problem in this area? I never used to have a problem with Mythdora (but I know that's well behind SVN).

I hope this gets picked up by the right people, cheers, Simon.

[anonymous]

I don't know if it is related but in SVN 15841 The following error is recored on Firefox error concole when Delete is clicked on the recorded programs page

Error: is_gecko is not defined Source File: ​http://xxxxxxxxx/mythweb/js/visibility.js Line: 85

[Rob Smith]

(In [15851]) Re #4608, this fixes the visibility.js error by switching over to prototypes methods

[Rob Smith]

Hello Simon,

Can you check current revision now so we are sure it's not the visibility.js error?

[simonwalls@…]

Hmmm, didn't know about the Firefox error console. It was indeed Firefox that I was browsing with.

OK, I'll get the latest svn and try again. Thanks.

[anonymous]

Simon,

Check out firebug sometime, it'll blow your mind :)

[Rob Smith]

Seems like it's all happy on my end. Feel free to reopen if still is a problem.

[simonwalls@…]

Sorry, but it's still a problem for me with svn 15851. I guess I am doing something unusual, kicking off recordings and then trying to stop them _before_ the program ends...?

Using the Firefox Error console, I get the following events when requesting the Backend Status page: Warning: Error in parsing value for property 'display'. Declaration dropped. Source File: ​http://192.168.1.8/mythweb/skins/default//style.css Line: 199 Error: _59 is not a function Source File: ​http://192.168.1.8/mythweb/js/prototype.js Line: 1

If I try and stop the recording by setting to 'Cancel this schedule' and clicking 'Update' then I get two more events in the Error Console: Warning: Error in parsing value for property 'display'. Declaration dropped. Source File: ​http://192.168.1.8/mythweb/skins/default//style.css Line: 199 Error: _59 is not a function Source File: ​http://192.168.1.8/mythweb/js/prototype.js Line: 1

This happens whether I have one recording in progress, or multiple, so I no longer think multirec is a factor.

If from the Recorded Programs page, I click on 'Still Recording: Edit' (which is a great, meaningful button) then in the Mythtv status area it says 'This showing was recorded' yet the Encoder Status is still showing as recording! Surely that's a mistake. It seems to me there is a case for another button in the Mythtv status area for a program, when it's recording, to perform a "Stop recording now" function. This would leave the partial recording present. Confirmation would be required for this of course.

It might be intended behaviour that that the only way to stop a recording in progress is to delete the mpeg file from the Recorded Programs page. Giving the option to stop a program recording part-way through might lead to users accidentally doing it. After all, we normally want to record whole programs! It's only my impulsive testing of multirec that revealed this.

But even if that is the case, the program status screen is incorrect when a program is being recorded and it says 'was recorded'.

Another little inconsistency is the Schedule Options box: when the button is in the 'Record only this showing' position, the top selection is called 'Cancel this schedule'. When you select that and click 'Update Recording Settings' the top selection is now called 'Don't record this program'. Is that right, or just an oversight?

Sorry to reopen, but these inconsistencies seem to have crept in since the last major release (0.20 fixes, ie. Mythdora 4) and it is confusing (and giving the wrong results) when trying to use it without experience.

[Rob Smith]

Woah there.

Line: 199 Error: _59 is not a function Source File: http://192.168.1.8/mythweb/js/prototype.js Line: 1

That is a packed JS that was removed in revision [15766] and then I killed the not a function bug in [15836]

It really seems like your not fully updated or your svn checkout is corrupt or the like.

Warning: Error in parsing value for property 'display'. Declaration dropped. Source File: http://192.168.1.8/mythweb/skins/default//style.css

You can ignore that one, it's not a problem.

If from the Recorded Programs page, I click on 'Still Recording: Edit' (which is a great, meaningful button) then in the Mythtv status area it says 'This showing was recorded' yet the Encoder Status is still showing as recording! Surely that's a mistake. It seems to me there is a case for another button in the Mythtv status area for a program, when it's recording, to perform a "Stop recording now" function. This would leave the partial recording present. Confirmation would be required for this of course.

When you go in to edit the recording, if you toggle the recording to cancel this schedule and hit save, it should stop recording.

The wording is wrong, but it's been that way forever. It's never been correct on that page sadly.

I'll look into fixing it, but it isn't related to the ticket of not being able to stop a recording.

Another little inconsistency is the Schedule Options box: when the button is in the 'Record only this showing' position, the top selection is called 'Cancel this schedule'. When you select that and click 'Update Recording Settings' the top selection is now called 'Don't record this program'. Is that right, or just an oversight?

That's right. You just canceled the recording, so it's no longer going to record it, and thus the "I'm not going to record it" option is selected.

Sorry to reopen, but these inconsistencies seem to have crept in since the last major release (0.20 fixes, ie. Mythdora 4) and it is confusing (and giving the wrong results) when trying to use it without experience.

Sadly these are long outstanding issues, not new ones.

[anonymous]

Thanks, that's great information. Sorry to bring up long-outstanding issues, they all seem new to me. I'll make do with them and when I'm able I could submit a patch.

Strange about the partial checkout thing - I shall have to re-checkout and try again. I guess this will stay as open until I do that. I'll report back.

[anonymous]

Right. I have uninstalled ('make uninstall' for all components), verified with SVN that my checkout is ok at 15851, and reinstalled.

I think the reason for the .js file being left behind is that in my haste to update (and I've never done it before) I omitted to delete and re-copy the /var/www/..mythweb directory. So it still had SVN 15741.... hence the error in the Console. Thanks for spotting that.

Anyway, I fully deleted the /var/www...mythweb folder and re-copied it from mythplugins/mythweb, stop & restart mythbackend and httpd and the problem still there.... I cannot stop a recording by clicking on 'Cancel this schedule' or by clicking the Never Record button. Only the 'Delete' button (adjacent to Never Record) or deleting the file from the Recorded Programs list make that happen.

So, it could well be real - sorry.

[Dibblah]

Simon, looking at this ticket and restating the problem:

1. A recording is in-progress (manual single record)
2. User goes to 'upcoming recordings' screen, selects 'Currently Recording: Edit'
3. Selects 'Don't record this programme' and Save.

User expectation:

1. In progress recording is cancelled
2. Schedule is removed.

Observed behavior:

1. Schedule is removed.
2. In-progress recording continues.

The reason for this apparent discontinuity is that in-progress recordings are not affected by the scheduler - If a recording is ongoing, it will not be stopped if it's removed from the schedule.

The main discrepancy here is that the UI is not explicitly separating the instance of this schedule from the schedule itsself. The 'schedule' referred to in this screen is the 'plan to record' - Not the program being recorded.

kormoc: Manually running the scheduler doesn't help (mythbackend --resched). The frontend uses RemoteStopRecording? for this functionality.

[simonwalls@…]

Thanks for looking at this one. You've got the user expectation and the observed behaviour exactly right - much more succinct than I put it....

The main discrepancy here is that the UI is not explicitly separating the instance of this schedule from the schedule itsself. The 'schedule' referred to in this screen is the 'plan to record' - Not the program being recorded.

That's exactly it. I, as a newbie user, was experimenting, but the problems I was having were based on what I read on Mythweb. (Now I've been using it longer, I don't record programs in that manner and expect to keep the partial recording).

There may still be a need for an ad-hoc recording method, as sometimes we don't want to record a whole program (example: A news broadcast has an item of interest).

I did state above that it seems to me there's a case for another button in the (Mythweb) status area for a program, when it's recording, to perform a "Stop recording now" function, but leave the partial recording present. It would be wise to require confirmation on that, of course.

And now I've got used to the fact that, as kormoc said: "The wording is wrong, but it's been that way forever. It's never been correct on that page sadly."

[Rob Smith]

(In [19040]) Fixes #4608, this actually cancels the currently recording program if you cancel its schedule