Can't exit video playback

[rafe101@…]

As the title says, sometimes I can not exit a recording/video file with escape or back. The only way is to skip to the end have it end naturally.

[paulh]

There's not enough information here to begin to fix this.

[rafe101@…]

I ran the frontend with verbose output for playback and studied the area where I tried exiting a video repeatedly. There's nothing there. Not a single indication that I pressed any button on the remote or keyboard until I started skipping ahead to get out of the video. I'm not sure what more information I can give you.

This really is quite annoying, especially since I am estimating that about 95% of the time there is no other way to exit video playback than skipping to the end.

[rafe101@…]

but maybe there is a tiny hint I can give:

the UI doesn't come back when a video ends. The display sticks on the last frame of the video and the only remedy is, again, advancing the video playback. I thought this was a separate issue, but maybe it's the same cause.

[drhunt@…]

I also experience the same issue about 50% of the time. The only way to fix it is kill the frontend. Was an issue on 0.27 and still an issue on 0.28. Any ideas where to look to debug this?

[rafe101@…]

I still don't know.

I won't even try live TV playback anymore since I wouldn't be able to skip forward to the end. I don't want to have to try and explain to my wife how to kill the frontend every time she wants to change a channel or watch a movie.

I have two other frontends and they all do this. Really annoying and I don't know how to provide more information than simply describing the problem.

[JYA]

Works for me... Using live to everyday with no issue whatsoever..

[Rafe101@…]

We know it works for others; it even works for us occasionally. It's not useful at all to tell us that. Like I said, I have three frontends that all do this. I've tried purging and reinstalling a frontend but it didn't help. The only thing I can think of is the database. It's the only common thing left. How that would affect not ending playback and returning to the UI, I have no idea.

[drhunt@…]

Backtrace when its in the broken state

#0  0x00007facec16c687 in ioctl () at ../sysdeps/unix/syscall-template.S:84
#1  0x00007facf017f058 in drmWaitVBlank (fd=99, vbl=0x7ffce9059a80) at vsync.cpp:234
#2  0x00007facf017f90f in DRMVideoSync::WaitForFrame (this=0x41280d0, sync_delay=40000) at vsync.cpp:323
#3  0x00007facf006428d in MythPlayer::AVSync (this=0x6bd6ab0, buffer=0x57e7080, limit_delay=false)
    at mythplayer.cpp:1927
#4  0x00007facf006847b in MythPlayer::DisplayNormalFrame (this=0x6bd6ab0, check_prebuffer=true)
    at mythplayer.cpp:2266
#5  0x00007facf006963e in MythPlayer::VideoLoop (this=0x6bd6ab0) at mythplayer.cpp:2470
#6  0x00007faceffc606c in TV::PlaybackLoop (this=0x41e7c50) at tv_play.cpp:1484
#7  0x00007faceffb3100 in TV::StartTV (tvrec=0x7ffce905a9e0, flags=0, 
    selection=std::vector of length 0, capacity 0) at tv_play.cpp:425
#8  0x000000000048d022 in PlaybackBox::Play (this=0x1a70960, rec=..., inPlaylist=false, ignoreBookmark=false, 
    ignoreProgStart=false, ignoreLastPlayPos=true, underNetworkControl=false) at playbackbox.cpp:2506
#9  0x000000000048b7de in PlaybackBox::PlayX (this=0x1a70960, pginfo=..., ignoreBookmark=false, 
    ignoreProgStart=false, ignoreLastPlayPos=true, underNetworkControl=false) at playbackbox.cpp:2287
#10 0x000000000048b43d in PlaybackBox::PlayFromBookmarkOrProgStart (this=0x1a70960, item=0x1c64750)
    at playbackbox.cpp:2218

Log shows

Apr 29 20:40:14 mythbox mythfrontend.real: mythfrontend[22788]: I CoreContext tv_play.cpp:424 (StartTV) TV::StartTV(): Entering main playback loop.

Code looks like this

 // Process Events
  424         LOG(VB_GENERAL, LOG_INFO, LOC + "Entering main playback loop.");
  425         tv->PlaybackLoop();
  426         LOG(VB_GENERAL, LOG_INFO, LOC + "Exiting main playback loop.");

It never exits the PlaybackLoop? function. All key presses (ie pause,rewind,fastforward etc) work correctly. It is just the exit behaviour which is broken.

I'll try and find some time to debug it further but this is what I've found so far. Maybe that helps.

I've had to teach my wife how to ssh into the box and run killall on the frontend as it happens so often.

[Rafe101@…]

That is exactly the behaviour I note. All other functions work (menu, info, skip, etc.) but not exit (most of the time; occasionally it does work). Thanks for looking into this. O don't have the time or knowledge, but of I can be of any help let me know. As for teaching the wife, I don't think either of us have the patience. I suppose a script could work, but I just do it from my phone when I need to.

[JYA]

Replying to Rafe101@…:

We know it works for others; it even works for us occasionally. It's not useful at all to tell us that. Like I said, I have three frontends that all do this. I've tried purging and reinstalling a frontend but it didn't help. The only thing I can think of is the database. It's the only common thing left. How that would affect not ending playback and returning to the UI, I have no idea.

It may not be useful to you to know, but seeing I'm the likely person who will have to work on this and fix it, not being able to reproduce it myself is kind of a big deal.

But of course, you're more than welcome to have a shot at it yourself.

I look forward to your resolution.

[Rafe101@…]

I'm thankful for the work that you do but saying "works for me... No issue whatsoever" isn't a very encouraging start.

[stuartm]

That's not what Jean Yves said Rafe, he said he can't fix what he can't reproduce. He is not saying there is no issue, if that were the case this ticket would have been closed. I hope you appreciate the difference.

[Rafe101@…]

Okay, I don't want to nitpick semantics; I literally copied what he said. In any case, we were trying to track down and describe the situation but were given no direction or suggestions.

[drhunt@…]

As Per Rafe's comment - Saying it works for me was less than helpful. Of course it works for Jean Yves. The question is why doesn't it work for us!

I've provided some info that helps pinpoint where the issue is. What I would like to know (I'm not familiar with the mythtv code/design) is what/where could it go wrong? What environmental or other factors could cause this to fail in some situations? What other info can we provide to help pinpoint this?

Is there any design docs, etc that I can have a look at? To help me understand it without having to reverse engineer it.

[stuartm]

Rafe - you selectively copied what he said making it sounds like he said something different.

What video driver are you both using? Which rendering mode - vdpau, XVideo, Other?

Backtrace suggests it may stuck waiting for vsync - although it would do this several times a second during normal playback so this is probably a red herring. When creating backtraces, do they all appear the same?

Which action are you using to exit playback, ESCAPE or STOP?

Which distro and distro version are you using? Are you building from source or using packages?

[rafe101@…]

Well...perception. It seemed very dismissive.

1. Nvidia on 2 of the machines and Nouveau on the third. The main machine is currently using VAAPI (just did a fresh Ubuntu LTS install on the office computer and haven't set up Myth yet), but have tried other video modes (VDPAU didn't perform well for me for some reason) since upgrading to 0.28 several months ago.

2. I couldn't find any differences. It's like the escape keypresses are completely ignored.

3. I have both STOP and ESCAPE mapped to my remote (on different buttons); neither works. I have tried escape with a keyboard as well.

4. All Ubuntu, all packages: 14.04 on two, 15.10 (until recently) on the other

Thanks for your assistance. I do appreciate it.

[drhunt@…]

Looks like it always gets stuck at the same place see new back trace from stuck live tv

#0  0x00007f0f8712d687 in ioctl () at ../sysdeps/unix/syscall-template.S:84
#1  0x00007f0f8b140058 in drmWaitVBlank (fd=85, vbl=0x7ffce20649a0)
    at vsync.cpp:234
#2  0x00007f0f8b14090f in DRMVideoSync::WaitForFrame (this=0x6e44120, 
    sync_delay=40000) at vsync.cpp:323
#3  0x00007f0f8b02528d in MythPlayer::AVSync (this=0x2a8b2c0, 
    buffer=0x59c1d18, limit_delay=false) at mythplayer.cpp:1927
#4  0x00007f0f8b02947b in MythPlayer::DisplayNormalFrame (this=0x2a8b2c0, 
    check_prebuffer=true) at mythplayer.cpp:2266
#5  0x00007f0f8b02a63e in MythPlayer::VideoLoop (this=0x2a8b2c0)
    at mythplayer.cpp:2470
#6  0x00007f0f8af8706c in TV::PlaybackLoop (this=0x38d0610) at tv_play.cpp:1484
#7  0x00007f0f8af74100 in TV::StartTV (tvrec=0x0, flags=0, 

If I step through the code I can see it exiting MythPlayer::VideoLoop? but just never can break out of TV::PlaybackLoop?

TV::PlaybackLoop? wantToExit = True kState = kState_WatchingLiveTV At line 1470 if (kState_ChangingState == state)

It looks like it should exit PlaybackLoop? when the state transitions to kState_None. Where in the code should this occur? I suspect this is the issue.

I'm current running mythbuntu 16.04 but experienced the same issue on 15.04. I'm using an Intel Graphics card with Just the normal "High Quality" render mode so No Vdpau, Vaapi.

[Thomas Kirk <thomas@…>]

I have just been directed here as I opened a ticket for what appears to be the same issue (I didn't see this ticket when I searched!).

I think I have the same issue. I upgraded to 0.28 (a fresh install of Mythbuntu 16.04). I didn't have the issue before though.

My frontend is using an Intel I965GM board with what I can work out i915 onboard graphics.

Let me know if I can be of assistance providing config/logs etc or if you need to know more about my hardware set up.

[anonymous@…]

Hello readers,

I also am experiencing the same issue since 'upgrading' to 0.28. I run NVidia on RedHat? Enterprise Linux and the affected system is via precompiled binaries (installed via package management utility).

I only observed this in 0.28 - I moved to 0.28 just a few days ago. I cannot step backward at all. Incidentally, I also once observed this behaviour whilst navigating movie titles in the MythVideo? GUI. (Not sure if related).

[djglaze@…]

Hello all,

I may have found something to help those who are having this issue. I have been having the same behavior described by others in this thread for several months now.

I was having it very intermittently with the version I was running prior to 0.28 (0.27.x), maybe once or twice a month. After the upgrade to 0.28, it had gotten significantly worse and was strangely getting gradually worse over time. Right after upgrading, it was happening maybe once out of every 3 or 4 recordings. Over the following week or two, strangely, it degraded to happening on every recording and the behavior changed from just not being able to exit playback to completely locking up the frontend.

Well, after restarting the frontend yet again to clear the problem, we decided to respond to the dialog box that pops up at startup, notifying us that our theme (ArcLight?) has a newer version available. (An upgraded version has been available since at least the 0.27 version of MythTV, but we just haven't bothered upgrading the theme.) After upgrading the theme, we've had zero problems with exiting playback or crashes of any kind. Maybe 8 recordings in a row so far with no problems.

We're not sure if this will be a fix for everyone, but it somehow was a fix for us. We didn't think that running an outdated theme would be harmful, but it appears to have been in this case. Hope this helps...

[stuartm]

Thank you for this detail, although it may prove to be a coincidence, it does suggest a new possible cause of the problem. Not the out of date theme, but the dialog prompting you to upgrade. If this or another similar dialog isn't being closed correctly, or worse is opening in the background during playback, it may be intercepting the ESCAPE keypresses so they simply never reach the playback window.

[Rafe101@…]

It could still be some sort of dialog causing this, but it's not the theme message and I don't know what it could be. All of my themes are up to date and each of the three frontends are using different ones. That's why I thought maybe there's something going on with the database since they all have this problem and that's the only common thing between them

[Rafe101@…]

Just checking if anyone has had any luck with this. I can sort of add something to this. For me, it isn't just the escape that is being ignored but any call to end playback (when it is having one of these fits). I have jump points to the video library, music, etc. When the playback is misbehaving and not responding to escape/back/stop it also won't respond to these jump points. The only way to exit is to skip to the end of the video or, in the case of livetv, kill the frontend process.

[kpeltola@…]

I am experiencing this issue as well - I upgraded to to .28 and all was well, and have kept up on the updates since, but I can't escape live TV/recordings and have to kill mythfrontend.real.

I also noticed - and perhaps this is related - if I go into any mythfrontend setup screen (say, appearance) and exit back to the main menu, then enter any setup menu, I can't navigate or enter changes (with remote or keyboard). Only ESC and ENTER are recognized - I can leave the menu entirely with ESC, or go to the next page with ENTER. When it is in this state, I can't navigate the menus and it doesn't even highlight the 'next' onscreen button that it normally would. Works after restarting mythfrontend.

[anonymous@…]

I also experience the same problem - with being unable to exit playback at times. I also experience the problem with the apparent lack of 'highlighted' <next> buttons. I also have a problem navigating in MythVideo?. If I view my list of movies, then scroll to the LAST movie in the list, the layout of the videos grid, 'shuffles' such that my last movie will ALWAYS be bottom right of the screen. At such time, I am unable to navigate <LEFT> or <RIGHT> - can only navigate <UP> or <DOWN>. My theme is 'MythCentre? Wide', newly installed (updated) since moving to MythTV 0.28 a handful of weeks ago.

--

Replying to kpeltola@…:

I am experiencing this issue as well - I upgraded to to .28 and all was well, and have kept up on the updates since, but I can't escape live TV/recordings and have to kill mythfrontend.real.

I also noticed - and perhaps this is related - if I go into any mythfrontend setup screen (say, appearance) and exit back to the main menu, then enter any setup menu, I can't navigate or enter changes (with remote or keyboard). Only ESC and ENTER are recognized - I can leave the menu entirely with ESC, or go to the next page with ENTER. When it is in this state, I can't navigate the menus and it doesn't even highlight the 'next' onscreen button that it normally would. Works after restarting mythfrontend.

[Rafe101@…]

I see that behavior as well, but I think it is different. That's at least manageable. One only needs to enter settings once and a while. It's a major pain in the ass to not be able to exit playback. In the absence of a better solution (I can tunnelssh in and kill the process) my wife has been instructed to use the case switch to shut the machine off. A reset is the only way I know for her to deal with it.

Sucks if I'm using the server somewhere else at the same time...

[brett@…]

I'm also seeing this. Running under CentOS 7

Under 0.27 I could sometimes only exit by skipping to the near the end of the recording and waiting got it to end naturally

Under 0.28, which I only compiled today

If I watch for less than 5 seconds I can exit using ESC If I watch for 25 minutes, having fast forwarded 2-3 times then ESC does nothing and skipping to the near the end of the recording it never exits.

I am using VDPAU

I have a log file from the frontend but it appears to be exactly the same for the failures after more than 25 minutes and for the success when less than 5 seconds.

However, the backend log shows errors

2016-06-15 19:55:00.207871 C [2515/2515] CoreContext programinfo.cpp:351 (ProgramInfo) - ProgramInfo(): Failed to find recorded entry for 0.
2016-06-15 20:20:00.211232 C [2515/2515] CoreContext programinfo.cpp:351 (ProgramInfo) - ProgramInfo(): Failed to find recorded entry for 0.
2016-06-15 20:22:00.208643 C [2515/2515] CoreContext programinfo.cpp:351 (ProgramInfo) - ProgramInfo(): Failed to find recorded entry for 0.
2016-06-15 20:26:05.002163 C [2515/2515] CoreContext programinfo.cpp:351 (ProgramInfo) - ProgramInfo(): Failed to find recorded entry for 162.
2016-06-15 20:26:11.237911 C [2515/2515] CoreContext programinfo.cpp:351 (ProgramInfo) - ProgramInfo(): Failed to find recorded entry for 162.

I've now enabled verbose logging for the "playback" level in the backend and will report if there is more information logged when it occurs again

[rodd@…]

I'm sseing this too.

Saw it occasionally on 0.27, a lot more common on 0.28.

Neither back nor stop exit playback.

I'm running Fedora 24 with 0.28 from rpmfusion. I've got a intel graphics adapter and I'm using 'VAAPI normal'.

Happy to gather some debug if someone can tell me how.

[rodd@…]

Just a thought. How many people with front ends that are problems are also using lirc on these front ends?

My main mythtv driver uses lirc and has this problem. I use my laptop on occasions, but can't recall having the problem and there's no lirc usage associated with the laptop.

[Rafe101@…]

Actually, I used to use lirc (albeit on a different myth version) and did not have the problem. I switched to using flirc dongles on two of the frontends and keyboard only for an office computer, so can't be that.

[Al@…]

Hi,

I also have the problem that ESC and STOP keys don't work, either on keyboard or remote control. In TV playback or video playback I can skip to the end and wait for the recording to finish but in LiveTV I have to kill the frontend.

Now on Mythtv 0.28 (when problems started). Have been using Mythtv on same PC with no problems since 0.23 in 2007. Running on Ubuntu 16.04.

[anonymous@…]

Replying to rodd@…:

Just a thought. How many people with front ends that are problems are also using lirc on these front ends?

My main mythtv driver uses lirc and has this problem. I use my laptop on occasions, but can't recall having the problem and there's no lirc usage associated with the laptop.

My system (0.28; NVidia; RedHat? Enterprise Linux; precompiled binaries) does indeed use LIRC. But it also occurs from a keyboard attached the the frontend machine directly. I haven't considered trying again without LIRC but sure can give it a go. I will update here (only) if it makes a difference.

--

--

[brett@…]

I'm using a USB keyboard / mouse.

Maybe we could get an "Stop playback" option added to the "Playback" menu item to try to work out if the ESC is not getting to the quit code, or the quit code is broken.

I've also implemented a workaround using xbindkeys. You need to ensure xbindkeys is running, then place the following into the X users ~/.xbindkeysrc

#Binds F3 to call the script
"~/bin/stop-progs"
    m:0x0 + c:70
    F3

Then I have the executable file ~/bin/stop-progs, also note the temporary file referenced below is removed by the .xinitrc that starts mythfrontend in the first place

#!/bin/bash
#try a soft kill first, but if it does not respond, terminate, with prejudice
if [[ -e '/tmp/tmp-kill-mythfrontend' ]]; then
	rm /tmp/tmp-kill-mythfrontend
	killall -9  mythfrontend
else 
	#this file is removed by .xinitrc
	touch /tmp/tmp-kill-mythfrontend
	killall mythfrontend
fi

[kpeltola@…]

I am still experiencing the issue - I was wondering if it had something to do with LIRC. I upgraded to .28, hadn't noticed the issue, and a couple of weeks later I installed a LCD panel using Mythlcdserver (which uses LCDproc and lirc).

I've been using lirc with no issues for my remote control for years - and the issue isn't limited to the remote, since I cant exit a recording with a keyboard either.

It's very bothersome. I can easily replicate and provide log info

[N. Mourocq <mourocq@…>]

I tried to stop the LCDd service. The key espace work fine after that.

[rodd@…]

I think we're on to something here.

I've check all my frontends and the one frontend that had issues had LCD enabled (even thou the box doesn't have an LCD panel) and since I've turned it off it's been working fine.

All the other (problem free) frontends didn't have LCD enabled.

[kpeltola@…]

I didn't try to stop the lircd service but went to Utilities/Setup?->Setup->Appearance->LCD device display. And unchecked "Enable LCD device". So far, everything is working perfectly (except, obviously, the LCD display). I can't replicate the issue so far. Very good!

[Rafe101@…]

Disabling the LCD feature in settings (wasn't working right since 0.28 anyway) does seem to clear this up. It also identifies something that I thought was part of this as a different issue (often, again not all the time, when a video reaches the end it sticks on the last frame and I have to advance forward for it to end and go to the GUI).

Great job guys tracking this down. I urge everyone to try this workaround.

[al@…]

Thanks for troubleshooting everyone. I'm just about to try disabling LCDd (seems to still be working OK for me in 0.28).

I'm rather sad to have to disable my VFD display. Over the last 10 years it has been faithfully telling me what's recording, even with the TV switched off. But I'd rather have the playback/exit issue fixed as it makes everything so much easier when you have several users.

Thanks.

[kpeltola@…]

Yes - I dual boot my front end media server as a Myth front/backend and a Windows steam PC - the display was helpful to see, at a glance, that myth was running when the display was off. Also, with the idea of the mythtv '10 foot interface' the display is near impossible to read when you are across the living room - but I love how it displays that progress bar when watching a video (or your position in the live tv buffer). Hopefully this issue can be fixed but for now I'm glad we figured out the root cause.

[stuartm]

Thank you for tracking this down, it should be much easier to identify the cause and fix now that we know where to start looking.

[anonymous@…]

Is this still being tracked?

[anonymous@…]

Is this still being tracked?

[Peter Bennett]

So if I read all this correctly, disabling LCD avoids this problem? If so, we need a developer who has an LCD to look into fixing MythTV so that both LCD displays and playback will work. I do not mind helping with this, but I do not have an LCD to test this on.

[Karl Egly]

Replying to pbennett:

I do not have an LCD to test this on.

Adding a LCD to the frontend is on my project list, too. When I looked at the ​list of supported interfaces I noticed "curses" and "xosd" which could be used for testing without soldering first. (there are others like svga and text)

[Peter Bennett]

Replying to anonymous@…:

Is this still being tracked?

Please use a real email address. Then you will receive updates

[Peter Bennett]

Replying to dekarl:

Adding a LCD to the frontend is on my project list, too. When I looked at the ​list of supported interfaces I noticed "curses" and "xosd" which could be used for testing without soldering first. (there are others like svga and text)

Thanks Karl. I will take a look at this bug after I have finished with the others I am working on. See if I can reproduce it with one of those fake devices.

[mythtv@…]

I have same issue on the frontend, where I have VFD (LCDd running dm140 driver). I am on mythbuntu 16.04.2 mythtv 0.28: MythTV Version : v0.28.1-19-g0037461 MythTV Branch : fixes/0.28 Network Protocol : 88 Library API : 0.28.20161120-1 QT Version : 5.5.1 Options compiled in:

linux profile use_hidesyms using_alsa using_oss using_pulse using_pulseoutput using_backend using_bindings_perl using_bindings_python using_bindings_php using_crystalhd using_dvb using_firewire using_frontend using_hdhomerun using_vbox using_ceton using_hdpvr using_ivtv using_joystick_menu using_libcec using_libcrypto using_libdns_sd using_libfftw3 using_libxml2 using_lirc using_mheg using_opengl using_opengl_video using_opengl_themepainter using_qtwebkit using_qtscript using_qtdbus using_sdl using_taglib using_v4l2 using_x11 using_xrandr using_xv using_profiletype using_bindings_perl using_bindings_python using_bindings_php using_freetype2 using_mythtranscode using_opengl using_vaapi using_vdpau using_ffmpeg_threads using_mheg using_libass using_libxml2

I remember having this issue (not able to exit video player or live tv) once before, but as it is couple of years back, I can't remember what was cause and how it was fixed. (it could be v0.26 or 0.27)

[Peter Bennett <pbennett@…>]

In 3cd374dd16d2257485468e0415892d417eb7520a/mythtv:

Fix for LCD device code hanging

When playing recordings if the audio changes (e.g. number of
channels change), it sends a message to the lcd server
from the wrong thread.
After this no LCD messages get through, but queue indefinitely.
The fix uses a slot to ensure messages are send from the
correct thread.

Refs #12566
Fixes #12567

[Peter Bennett <pbennett@…>]

In 14f82aa54c2825b58b08499a2f448dd6a155fb05/mythtv:

Fix for LCD device code hanging

When playing recordings if the audio changes (e.g. number of
channels change), it sends a message to the lcd server
from the wrong thread.
After this no LCD messages get through, but queue indefinitely.
The fix uses a slot to ensure messages are send from the
correct thread.

Refs #12566
Fixes #12567

(cherry picked from commit 3cd374dd16d2257485468e0415892d417eb7520a)

[Peter Bennett]

Please let me know if this fixes the problem.

[Al@…]

I'd love to help test this as I have the LCD problem. Trouble is, I'm a lowly user running Ubuntu 16.04 with MythTV from the official packages and I haven't the faintest idea how to install patches.

Is there a simple way for me to test this for you or should I leave it to those who understand the patching process?

This is my current version (I ran mythfrontend --version)

MythTV Version : v0.28.1-2-g46bd4f4 MythTV Branch : fixes/0.28 Network Protocol : 88 Library API : 0.28.20161120-1 QT Version : 5.5.1

[Peter Bennett]

Wait until tomorrow, then install from the mythbuntu PPA

​https://launchpad.net/~mythbuntu/+archive/ubuntu/0.28

I recommend go to that page first and make sure you see the current date in the package list, so you are not wasting your time in case it is not there yet.

[Al@…]

Excellent, I'll try that.

Thanks for all your hard work, btw.

[Al@…]

I've tested this today with the latest fixes from the ppa as suggested.

All seems to work OK with the playback side of things (so far, but it'll take a few days to know for sure).

Unfortunately, however, the VFD now seems to only work for a while. It displays playback info, reflects the menus as I scroll through them. But I've just left it on the Recordings screen and gone out for half an hour. When I came back the VFD was showing a load of strange characters and now does not wake up when I move around in MythTV. This behaviour did not happen last year before I disabled LCDd.

[Peter Bennett]

Replying to Al@…:

Unfortunately, however, the VFD now seems to only work for a while. It displays playback info, reflects the menus as I scroll through them. But I've just left it on the Recordings screen and gone out for half an hour. When I came back the VFD was showing a load of strange characters and now does not wake up when I move around in MythTV. This behaviour did not happen last year before I disabled LCDd.

Please check if there are any error messages in the frontend log when this happens. Also, did the frontend suspend during that time? Also check if mythlcdserver is still running on the frontend machine when it happens:

ps -C mythlcdserver

[Al@…]

Hi again, Playback had been ok when I posted. However a couple of recordings since have now shown the same behaviour as before unfortunately.

I'll monitor keep an eye on things and post back when I have some logs to share.

Cheers.

[al@…]

Apologies, after the machine has been shut down since I posted the other day, what seems to be happening now is:

LCD screen keeps its message during playback but when you come back to a menu, the display remains for the period set as "Menu pop-up time" and then goes to some garbled characters. It does, however now revert to expected display when I start playback again.

ps -C mythlcdserver returns 
  PID TTY          TIME CMD
 2312 ?        00:00:53 mythlcdserver

Sadly, I thought that the using of the back/exit key to exit playback might have started working. however, what seems to be happening is when I try to test it, it always seems to work. It tends to be when I settle down to watch something properly for 10 minutes or more that it locks up and will not exit playback. On one occasion in the last couple of days the frontend has locked completely but all the other times I've been able to exit playback by using the right arrow keys to go to the end of the recording. At this point the recording stops on its own.

I've been running

tail -f frontend.log

all the time I've been watching and absolutely nothing appears in the log when I press the exit key if it locks. If the recording exits properly (when it's only been running a short time) then this appears:

mythfrontend[24419]: I CoreContext tv_play.cpp:426 (StartTV) TV::StartTV(): Exiting main playback loop.

[Peter Bennett]

I am running a simulated LCD on a remote frontend. Are you using a remote frontend or a combined frontend / backend?

I do not get the hanging problem. The LCD displays the playing program name and time elapsed. I tried twice playing for 30 minutes, press escape and it ends playback immediately and returns to the recording list.

After exiting from playback, after the "menu popup time", it alternates between displaying the time and the server details (see below). You can avoid the server details and only see the time display by using ServerScreen=no in /etc/LCDd.conf.

+----------------------------------------+
|## LCDproc Server ######################|
|Clients: 0                              |
|Screens: 0                              |
|                                        |
|                                        |
|                                        |
|                                        |
|                                        |
|                                        |
|                                        |
+----------------------------------------+

+----------------------------------------+
|            Fri Apr 28 2017             |
|                                        |
|                                        |
|                                        |
|                                        |
|                2 38 PM                 |
|                                        |
|                                        |
|                                        |
|                                        |
+----------------------------------------+

What sort of garbage do you see and could it be related to your problem?

If you are running a combined frontend / backend, do you see messages from the backend? Perhaps they are causing the problem? Perhaps the garbage you see is from the backend?

[Peter Bennett]

I tried LCDd on a combined frontend / backend, with the same results. After watching for 30 minutes, escape worked immediately.

I looked at the LCDProc documentation and found something that may be relevant.

​http://lcdproc.sourceforge.net/docs/lcdproc-0-5-5-user.html#menu-section

I may be completely off base here, as I know little about the LCDProc package.

Please look at your /etc/LCDd.conf file and if it has a [menu] section with a line MenuKey=Escape, please comment that line and see if it solves the problem.

[Al@…]

LCDdisplay

[Al@…]

Hi, please see attached LCDdisplay file for an idea of what I see. This happened before and is still happening after adding the ServerScreen?=no line and commenting out the MenuKey?=Escape line.

I have my Menu pop-up time set to 60 seconds (set in the Frontend) and the display stays on for this time. Soon after this the screen changes to the one in the attachment. I was seeing the LCDproc Server screen similar to yours sometimes, I think just before the garbage screen but that doesn't seem to appear now since adding the ServerScreen? line. At no time, since re-enabling the LCD this year, have I ever seen the time display like yours. I'm pretty sure I used to see it last year before I disabled the LCD because of this problem.

I haven't been able to reproduce the problem with exiting playback yet but I have only just made the changes so will need to use for a day or 2 to see if this is now working.

Thanks.

[Al@…]

Sorry, forgot to answer - I'm using a combined Frontend/Backend? system on Ubuntu 16.04

I'm also currently using v0.28.1-21-ge26a33c. I would like to use the Mythbuntu ppa to update to 0.29 so that I can use the Vbox patches ​https://forum.mythtv.org/viewtopic.php?f=9&t=1724 Can I do this and still keep testing your LCD patches/suggestions?

[Peter Bennett]

Your strange LCD display may be the attempt to display the time. In frontend setup -> appearance -> LDC Device Display, check if you have "Display large Clock". If so, try unchecking that option. In order to have the change take effect you have to close the frontend, then run "killall mythlcdserver" then start frontend again.

With "Display large Clock", it displays the clock like this (see below), using underscores, slashes, pipes, dots, etc. Possibly your LCD does not support underscores and pipes. I can see the two dots in your display, so maybe that is what is happening. This is 10:09 displayed with "large clock":

    _   _  _  
  || |.| ||_| 
  ||_|.|_| _| 
              

Regarding version 29 - all of the changes, patches, suggestions apply there. So feel free to test this on version 29.

[Al@…]

Oh blimey, thanks. Could've sworn I'd gone through all the LCD options in the frontend setup - maybe I forgot to restart the LCD server or something.

Anyway, fantastic, that's fixed the display. Now fingers crossed for the playback issue.

Thanks again.

[Al@…]

Bad news I'm afraid. Watched a programme last night and unfortunately the playback stuck again, just like before. The Escape, Back & Stop keys do not work and the only way to stop playback is to forward skip to the end or wait until playback naturally gets to the end.

Cheers

[Peter Bennett]

Did you restart the machine after changing LCDd.conf?

Since I cannot recreate it, to debug further we need to turn on action debugging and gather the log. This requires a small change and recompile. Let me know if you are able to do that. If you are unable to do that, let me know the version of ubuntu you are using and whether your machine is 32 bit or 64 bit. I can build you the affected library and you can copy into the system temporarily. Let me know if you want to try this approach.

[Al@…]

Hi, I'm pretty sure I did, especially as the machine powers off when not in use and starts itself up to record. Anwyway I'll try watching something again tomorrow (several restarts since editing LCDd.conf) and see if it's still a problem.

Yes, happy to do whatever is easiest. I'm afraid I'd need instructions to recompile as I've never done that before or happy to copy something you build if you can spare the time - thanks.

My details:

user@myth64:~$ lsb_release -a
No LSB modules are available.
Distributor ID:	Ubuntu
Description:	Ubuntu 16.04.1 LTS
Release:	16.04
Codename:	xenial
user@myth64:~$ uname -a
Linux myth64 4.4.0-62-generic #83-Ubuntu SMP Wed Jan 18 14:10:15 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux

[Al@…]

Just watched another programme and was again unable to stop playback without jumping to the end.

[Peter Bennett]

Instructions for debugging. This is only for mythtv version fixes/0.28 on Ubuntu 16.04.

Download this file:

​https://www.dropbox.com/s/wcmyedmxzexxo8a/libmythtv-0.28.so.0?dl=1

Create a directory in your home directory, testlib, i.e. /home/xxxxxx/testlib. Copy that file in there.

Run the frontend from the command line as follows:

export LD_LIBRARY_PATH=/home/xxxxxx/testlib
mythfrontend.real --logpath=$HOME

Play your recording until it is not responding and gather the log file from the home directory. You will see every keyboard action you take logged there, like this (see below). The time of each event is at the beginning of the line. Note the exact time when you pressed escape with no result, and we can look see what the log says

(event) - TV::event(): keypress: 16777216 'ESC'
(ProcessKeypressOrGesture) - TV::ProcessKeypressOrGesture(): ignoreKeys: 0
(ProcessKeypressOrGesture) - TV::ProcessKeypressOrGesture(): handled(1) actions[0](BACK)
(ProcessKeypressOrGesture) - TV::ProcessKeypressOrGesture(): handled(1) actions[1](ESCAPE)

You can vary the instructions as far as what directories you use or how you launch it, this just gives you a guide.

To understand the number next to keypress, convert it to hex and look here: ​http://doc.qt.io/qt-5/qt.html#Key-enum

[Al@…]

Hi,

Thanks for all this. I'm afraid I've updated now to the 0.29 mythbuntu ppa as per our discussions a few days ago. Is it easy for you to do this again for 0.29? Sorry, I realise this is probably a lot of work for you but it's much appreciated!

Cheers.

[Peter Bennett]

For version 29, here is download location for the file to put in the testlib directory. Other instructions are the same as for version 0.28:

​https://www.dropbox.com/s/9s9q8jqp94di6w2/libmythtv-29.so.29?dl=1

[Alastair <al@…>]

Replying to pbennett:

For version 29, here is download location for the file to put in the testlib directory. Other instructions are the same as for version 0.28:

​https://www.dropbox.com/s/9s9q8jqp94di6w2/libmythtv-29.so.29?dl=1

Hi,

Here are my files: ​https://www.dropbox.com/sh/4az6gbygqzgzxai/AACBJ9pCvrp1ehrngNDMdzmva?dl=0

I had to include the full path to the file in the Include command, ie export LD_LIBRARY_PATH=/home/xxxxxx/testlib/libmyth-29.so as just specifying the directory didn't work.

I managed to reproduce a couple of hangs:

The first at 1209 caused the whole frontend to hang with no way to exit it except by killing the process.

The second time, at 1250, I was unable to exit from playback with the normal Stop or escape keys but I was able to fast forward to the end of the recording and then the playback would stop.

On both occasions I couldn't see anything appear in the frontend log that meant anything to me but there was a message in the terminal that didn't seem to make it to the log so I've included some of the screen output in case it helps. There also doesn't seem to be any recording of the keypresses as in your examples. I tried using both a remote control and a keyboard.

[Roger Siddons]

The "WARN Launch not found" terminal messages are coming from MHEG. ​https://www.mythtv.org/wiki/MHEG

Please try again with Interactive TV disabled.

[Alastair <al@…>]

Thanks, I've just disabled the Interactive TV and so far the quick test I did earlier (where I opened up one of my recordings and moved back and forth repeatedly a number of times and also left it playing for 10 minutes or so) has not reproduced the error. This is just a quick test so time will tell.

If anyone else who was affected is still following this thread and can help by trying this, you can disable Interactive TV by going to your Frontend - Setup -> Video -> Playback OSD and disabling the two Interactive TV options.

Please report back your experience. Thanks.

[Peter Bennett]

Replying to Alastair <al@…>:

I had to include the full path to the file in the Include command, ie export LD_LIBRARY_PATH=/home/xxxxxx/testlib/libmyth-29.so as just specifying the directory didn't work.

When you did that did you get an error message? What was the error? There may be some incompatibility in that library that I sent you.

The way you ran it, with the full file name in the LD_LIBRARY_PATH did not use the library I sent you, that is the wrong syntax.

[Alastair <al@…>]

Here's what I typed & the response:

family@myth64:~$ export LD_LIBRARY_PATH=/home/family/testlib
family@myth64:~$ mythfrontend.real --logpath=$HOME
mythfrontend.real: symbol lookup error: mythfrontend.real: undefined symbol: _ZN18MythRAOPConnection14g_rsaLastErrorE

[Alastair <al@…>]

Quick update from my point of view:

Disabling Interactive TV has not helped. The problem with stopping playback still happens for me.

If I simply play back a recording from the start without using the arrow keys to move forward or back then it rarely (perhaps never) seems to hang. Most of the time we play back recordings and use the L & R arrows to skip forward and back for adverts or when kids keep interrupting. We often use P to pause and resume as well. When we do this and a recording lasts say 10 minutes or more then it nearly always seems to hang when we press back or stop (remote or keyboard).

I'm disabling the LCD in frontend setup for now as this is a real problem for the rest of the family who don't know any other way to kill the frontend when it hangs (sometimes we can advance to the end of a recording but often the frontend just hangs when we press stop, Esc or back.

I'm happy to try some more tests if pbennett is able to help with another library.

[Alastair <al@…>]

Replying to pbennett:

I am running a simulated LCD on a remote frontend. Are you using a remote frontend or a combined frontend / backend?

I do not get the hanging problem. The LCD displays the playing program name and time elapsed. I tried twice playing for 30 minutes, press escape and it ends playback immediately and returns to the recording list.

Please see my notes on playback in comment 79:

If I simply play back a recording from the start without using the arrow keys to move forward or back then it rarely (perhaps never) seems to hang. Most of the time we play back recordings and use the L & R arrows to skip forward and back for adverts or when kids keep interrupting. We often use P to pause and resume as well. When we do this and a recording lasts say 10 minutes or more then it nearly always seems to hang when we press back or stop (remote or keyboard). 

After exiting from playback, after the "menu popup time", it alternates between displaying the time and the server details (see below). You can avoid the server details and only see the time display by using ServerScreen=no in /etc/LCDd.conf.

+----------------------------------------+
|## LCDproc Server ######################|
|Clients: 0                              |
|Screens: 0                              |
|                                        |
|                                        |
|                                        |
|                                        |
|                                        |
|                                        |
|                                        |
+----------------------------------------+

+----------------------------------------+
|            Fri Apr 28 2017             |
|                                        |
|                                        |
|                                        |
|                                        |
|                2 38 PM                 |
|                                        |
|                                        |
|                                        |
|                                        |
+----------------------------------------+

What sort of garbage do you see and could it be related to your problem?

If you are running a combined frontend / backend, do you see messages from the backend? Perhaps they are causing the problem? Perhaps the garbage you see is from the backend?

[Peter Bennett]

Replying to Alastair <al@…>:

If I simply play back a recording from the start without using the arrow keys to move forward or back then it rarely (perhaps never) seems to hang. Most of the time we play back recordings and use the L & R arrows to skip forward and back for adverts or when kids keep interrupting. We often use P to pause and resume as well. When we do this and a recording lasts say 10 minutes or more then it nearly always seems to hang when we press back or stop (remote or keyboard).

This is good information. When I tested before, I just let it run for 30 minutes then hit escape. That always worked. I will try with using arrows and pauses and see if I can find anything.

[kpeltola@…]

I don't know if anyone else was experiencing this related issue that I was having when LCD is enabled. Just a reminder since it was posted quite a while ago:

I also noticed if I go into any mythfrontend setup screen (say, appearance) and exit back to the main menu, then enter any setup menu, I can't navigate or enter changes (with remote or keyboard). Only ESC and ENTER are recognized - I can leave the menu entirely with ESC, or go to the next page with ENTER. When it is in this state, I can't navigate the menus and it doesn't even highlight the 'next' onscreen button that it normally would. Works after restarting mythfrontend.

[Peter Bennett]

Replying to kpeltola@…:

I don't know if anyone else was experiencing this related issue that I was having when LCD is enabled. Just a reminder since it was posted quite a while ago:

I also noticed if I go into any mythfrontend setup screen (say, appearance) and exit back to the main menu, then enter any setup menu, I can't navigate or enter changes (with remote or keyboard). Only ESC and ENTER are recognized - I can leave the menu entirely with ESC, or go to the next page with ENTER. When it is in this state, I can't navigate the menus and it doesn't even highlight the 'next' onscreen button that it normally would. Works after restarting mythfrontend.

That was reported as #12884. It is not related to LCD, it happens whether LCD is enabled or not.

[Peter Bennett]

Replying to Alastair <al@…>:

I'm happy to try some more tests if pbennett is able to help with another library.

I am still unable to recreate it. If you can run another test maybe we can nail it.

I set this up so that it will not affect any of your normal mythtv installation. This is for version 29. Download mythtest.tgz from ​https://www.dropbox.com/s/87demboq49359t6/mythtest.tgz?dl=1

In your home directory, run this

tar xvf mythtest.tgz

That will create a directory proj/mythtv-build/myth-msttst/ in your home directory. Run this

ln -s .mythtv .mythtv-msttst

That will create a link to your .mythtv directory. Download myth.sh from here ​https://www.dropbox.com/s/gsix2pruejfijpn/myth.sh?dl=1

To start the frontend use this

./myth.sh msttst mythfrontend --logpath $HOME

If you get to the situation where pressing escape does not work, note the time and let me have the log. The log and the console will show each keystroke during playback and what was done with it.

If there is any problem running this let me know.

[Alastair <al@…>]

Replying to pbennett:

If you get to the situation where pressing escape does not work, note the time and let me have the log. The log and the console will show each keystroke during playback and what was done with it.

If there is any problem running this let me know.

Here we go. Please see this log file: ​https://www.dropbox.com/s/azwusv6g7ht2cc2/mythfrontend.20170516072723.5465.log?dl=0

I pressed Escape about 3 times at 0924 and the frontend just hung. Hope you can make something from it.

In case it helps, here's the log from playing the same programme just for a few seconds where the Escape key worked OK: ​https://www.dropbox.com/s/gu5int8fc6wlbmd/mythfrontend.20170516092003.7409.log?dl=0

[Peter Bennett]

The log shows that the escape is getting to the TV class which handles all of the keyboard commands, and it is invoking the correct routine. Something is then hanging the system. I am unable to recreate it, I tried some of the things you did during playback.

I cannot find anything in the LCD processing that could cause this. The LCD code runs in the main thread, and perhaps it is hanging. Putting it in a separate thread may help, since the invocation uses slots, but I have nothing to support the fact that the code may be hanging in the LCD class.

Do you notice anything different about the LCD display when this happens? Does it continue to update and keep up with the correct time, until you press escape, or is there any lag or strange display. One thing it does upon exiting playback is to turn off LEDS that indicate stereo, surround sound, HD, etc. Do you have such LEDs?

[Alastair <al@…>]

I cannot find anything in the LCD processing that could cause this.

Oh dear, that's really annoying.

Do you notice anything different about the LCD display when this happens? Does it continue to update and keep up with the correct time, until you press escape, or is there any lag or strange display.

No, nothing different. I tried again today and the LCD display continues updating the display while playing and also after pressing Escape when playback has frozen. After the playback froze I watched the LCD quite happily cycle through 3 displays:

1. First part of the name of my programme,
2. Second part of the name of my programme and
3. The channel name
4. Back again to 1

I've just changed the settings to only show the time of day and I'll try again later and see if the time continues to update.

One thing it does upon exiting playback is to turn off LEDS that indicate stereo, surround sound, HD, etc. Do you have such LEDs?

No, I don't think so.

[Alastair <al@…>]

Do you notice anything different about the LCD display when this happens? Does it continue to update and keep up with the correct time, until you press escape, or is there any lag or strange display.

I've just changed the settings to only show the time of day and I'll try again later and see if the time continues to update.

Yes the time carries on updating. Have just had the issue again today. It's now an hour or so later and the time is still updating.

The freeze happened about 08:24 today. In case it helps, here are the last few lines from mythfronted.log (run normally, not your special version)

May 22 08:17:51 myth64 mythfrontend.real: mythfrontend[2655]: I CoreContext? mythrender_vdpau.cpp:616 (CheckOutputSurfaces?) VDPAU: Added 2 output surfaces (total 4, max 4)

May 22 08:18:02 myth64 mythfrontend.real: mythfrontend[2655]: N CoreContext? mythplayer.cpp:2231 (PrebufferEnoughFrames?) Player(1): Waited 104ms for video buffers AAAAAAAAUUUuLL

May 22 08:18:02 myth64 mythfrontend.real: mythfrontend[2655]: N CoreContext? mythplayer.cpp:2231 (PrebufferEnoughFrames?) Player(1): Waited 104ms for video buffers AAAAAAAAAAAAAA

May 22 08:25:13 myth64 mythfrontend.real: mythfrontend[2655]: E Decoder mythplayer.cpp:3504 (DecoderGetFrame?) Player(1): Decoder timed out waiting for free video buffers.

May 22 09:28:39 myth64 mythfrontend.real: mythfrontend[2655]: N CoreContext? tv_play_win.cpp:100 (gestureEvent) TV Play Window Click

[Peter Bennett]

I will not be able to look at this for the next few weeks. I can come back to it mid June. Since I cannot reproduce it I can try changing the way some things work and give you a version to test, hopefully to find something that solves this.

[Alastair <al@…>]

OK, thanks.

[JYA]

I seriously doubt it it has anything to do with the LCD stuff..

It's architecturally impossible for anything to do with mythlcd to block the player.

[Alastair <al@…>]

Interesting. There is no doubt, however, that disabling LCDd service and unticking the LCD in the frontend settings completely prevents this problem from happening.

In fact you don't need to disable or even stop the LCD service - just unticking the option in Mythfrontend is enough to prevent the problem.

This all started around 0.27. Before that playback and the LCD screen worked fine for years.

Hope this helps.

[Jonatan Lindblad <jlindblad@…>]

In bdbc6363a311f08cdb61eab81d62243b56b7bd12/mythtv:

TV: Fix ESCAPE being ignored

The cause was that lcdVolumeTimerId was never set to 0 after killing it.
Since timer IDs are reused by Qt the timer started when ESCAPE was
pressed to exit playback could be treated as lcdVolumeTimerId and ending
up never being processed. This only happened if the LCD support was
enabled and the volume was changed.

Fixes #12566

[Jonatan Lindblad <jlindblad@…>]

In e3b8adeb88e42719ce2acae9eb3a2981a27eba68/mythtv:

TV: Fix ESCAPE being ignored

The cause was that lcdVolumeTimerId was never set to 0 after killing it.
Since timer IDs are reused by Qt the timer started when ESCAPE was
pressed to exit playback could be treated as lcdVolumeTimerId and ending
up never being processed. This only happened if the LCD support was
enabled and the volume was changed.

Fixes #12566

(cherry picked from commit bdbc6363a311f08cdb61eab81d62243b56b7bd12)

[Alastair <al@…>]

Thanks for the note. Does this mean you've managed to fix it?

I'm now on 0.29 from the Mythbuntu ppa. What do I have to do to get the fix please? Will it make its way into the ppa shortly?

Thanks for all your help.

[Alastair <al@…>]

All working nicely now. Thanks for the fix.