[mythtv-users] FE artwork periodically flashes away

[Hika van den Hoven]

Hoi Mark,

Thursday, November 13, 2014, 12:05:21 AM, you wrote:



>> -----Original Message-----
>> From: mythtv-users-bounces at mythtv.org [mailto:mythtv-users-
>> bounces at mythtv.org] On Behalf Of Joseph Fry
>> Sent: Tuesday, 4 November 2014 2:17 PM
>> To: Discussion about MythTV
>> Subject: Re: [mythtv-users] FE artwork periodically flashes away
>> 
>> 
>> 
>>> On Mon, Nov 3, 2014 at 8:07 PM, Hika van den Hoven <hikavdh at gmail.com>
>>> wrote:
>>> 
>>> 
>>>Hoi Mark,
>>>      Just a thought, have you looked into issues concerning powersave?
>>> Also
>>>      is the metadata on another physical disk, that for instance spins
>>> down.
>> 
>> 
>> 
>> 
>> The error doesn't point at a file being unavailable.
>> 
>> Looking at the code for playbackbox.cpp, it looks like the handlepreview
>> event is getting spawned multiple times... almost as though you moved away
>> and back to the item.
>> 
>> I don't know the code well enough to understand what would spawn that
>> event, other than moving up or down the list, but I suspect that it's not
>> related to your hdd spinning down or the file being otherwise inaccessible.
>> 
>> I suspect that it is related to powersaving.
>> 
>> Check your frontends  "FrontendIdleTimeout" value (you can see it in the
>> general setup screen (I think) or in mythweb (in the settings > mythtv page
>> after selecting the frontend from the dropdown).  I wonder if perhaps when
>> this timer expires it triggers something that takes the focus away from the
>> frontend briefly... setting off a new handlepreview event when the focus
>> returns?  Maybe it tries several times and gives up.
>> 
>> Perhaps you didn't disable xscreensaver as completely as you think, and it's
>> stealing the focus over and over before finally failing?  You could try disabling
>> xscreensaver by stopping the service altogether?
>> 
>> I could be way off base, this is just speculation, but something is definitely
>> triggering these events multiple times before giving up.
>> 
>> 
>> 
> Thanks Hika and Joseph for the responses, much appreciated.

> I've managed to have a bit of luck here. I started trying to time
> and count the flashes to identify a pattern. Turns out that the
> number of flashes equalled the number of recordings in the Delete recording group.

> Of course at that point the immediate question was - why are there
> recordings stuck in the Delete group? And on a lucky tangent I went.

> About 6 months ago my recording drives started to get full. So I
> moved a pile of recordings that were shows we watch when there is
> nothing else to watch over to a NAS. I thought everything was
> working fine but it turns out MythBE could not 'unlink' the
> recordings as part of the delete process. I could still watch the
> recordings, and the mythtv user (that runs my backend) could rm / cp
> / mv the recordings but MythBE could not 'unlink' (whatever 'unlink'
> actually means in practice). So every time it tried to 'unlink' I
> got that series of flashes on the FE. As we gradually watched (and
> deleted) more of those shows the problem became more obvious (more flashes).

> I double checked permissions on the folders but everything looked fine.

> I checked my /etc/fstab file to see how the CIFS shares were
> mounted. This was the original line:

> //192.168.1.22/ServerThree/ServerTwo        /media/servertwo       
> cifs   
> credentials=**deleted**,gid=1001,uid=1001,nounix,iocharset=utf8,file_mode=0777,dir_mode=0777 0       0

> I did a quick read on the 'nounix' option and it sounded like a
> possible candidate for what was going on ("nounix" option disable
> CIFS Unix Extensions so that no UNIX ACL, path and lock will be used
> - so maybe MythBE couldn’t lock file to unlink or something?) anyway
> I removed 'nounix' and remounted and voila - over the next 5min all
> the recordings were deleted. And once the to-be-deleted recordings were gone the flashing stopped.

> I still get the occasional flash but only a single flash and I
> assume it is only shortly after I delete a recording.

> For the record these are the messages I was getting in the backend
> log about once (one block) every 15minutes or so:

> 2014-11-04 11:23:55.215723 N [3267/3398] Expire autoexpire.cpp:641
> (SendDeleteMessages) - Expiring 2136 MB for 1099 at
> 2014-07-20T09:57:00Z => "Hamish And Andy's Gap Year South America"
> 2014-11-04 11:24:00.278920 E [3267/13004] DeleteThread
> mainserver.cpp:2307 (OpenAndUnlink) - Error deleting
> '/media/serverthree_s1/Myth_Temp_Rec/1009_20131003110000.mpg' could not unlink
>                         eno: Device or resource busy (16)
> 2014-11-04 11:24:00.279584 E [3267/13004] DeleteThread
> mainserver.cpp:2279 (DeleteFile) - Delete Error
> '/media/serverthree_s1/Myth_Temp_Rec/1009_20131003110000.mpg'
>                         eno: Device or resource busy (16)
> 2014-11-04 11:24:00.280975 E [3267/13004] DeleteThread
> mainserver.cpp:2059 (DoDeleteThread) - Error deleting file:
> /media/serverthree_s1/Myth_Temp_Rec/1009_20131003110000.mpg. Keeping metadata in database.

> The only catch to all this - I'm not clear on exactly how the
> delete failure translates into metadata flashing on the screen.
> There is clearly a link (at least on my setup, sample size = 1), but
> the mechanics of that part elude me.

Nice Find! The 'unlink' in this context possibly suggests to me there
is a lock that cannot been released needed to free the file for
deletion.
Maybe you could look at the slow deletion setting in the backend.
Possibly the deletion locks up the network connection for a short
while.


Tot mails,
  Hika                            mailto:hikavdh at gmail.com

"Zonder hoop kun je niet leven
Zonder leven is er geen hoop
Het eeuwige dilemma
Zeker als je hoop moet vernietigen om te kunnen overleven!"

De lerende Mens