[mythtv] Myhthfrontend sitting at "Please Wait"

[David Hampton]

On Wed, 2018-05-09 at 01:18 +0000, Sam Davis wrote:
> Hello,
> 
> Now that it appears that I have issues both with the backend and
> frontend systems (meaning the system is basically "stuffed") do we
> have any idea when fixes will be pushed through for these? The
> backend shows same type of error as frontend and looks like when a
> recording tries to start where it needs to assign a tuner. I am
> running separate backend and frontend and using 3xUSB (PlayTV)
> tuners. I am after some direction as to whether the problem is
> understood and being worked on or should I resort to a rebuild back
> to Fedora 27? If there are any diagnostics that you want me to do I
> am happy to help.

I just committed Gary's two patches to versions 0.28 and later.  I
don't know how long it will take for those to be incorporated into the
rpms at rpmfusion.

David



> Thanks
> Sam
> From: mythtv-dev <mythtv-dev-bounces at mythtv.org> on behalf of Sam
> Davis <samdavis at outlook.com.au>
> Sent: Tuesday, 8 May 2018 8:36 AM
> To: Development of MythTV
> Subject: Re: [mythtv] Myhthfrontend sitting at "Please Wait"
>  
> Is it also worth posting in user forums warning of upgrading to
> fedora 28 until fixes are in place?
> 
> Get Outlook for iOS
> From: mythtv-dev <mythtv-dev-bounces at mythtv.org> on behalf of David
> Hampton <mythtv at love2code.net>
> Sent: Tuesday, May 8, 2018 12:20:36 AM
> To: Development of MythTV
> Subject: Re: [mythtv] Myhthfrontend sitting at "Please Wait"
>  
> On Mon, 2018-05-07 at 14:15 +0000, Gary Buhrmaster wrote:
> > On Mon, May 7, 2018 at 12:29 PM, David Hampton <mythtv at love2code.ne
> t>
> > wrote:
> > .....
> > > Agreed.  I should have also said that I don't have any problem
> with
> > > playback of live tv, recorded tv, or recorded videos.  I was just
> > > pointing out that its not all F28 installs that crash, but
> there's
> > > something specific about the users systems that is causing the
> > > crashes.
> > 
> > Yes, it is all going to be specifics.
> > 
> > The first patch (processing the transport stream program
> > descriptors) is going to be source stream specific (and
> > when, how, and if (from the transport stream) you get the
> > program info).  I am not surprised that some OCUR
> > tuners (what i think was the first report), that are known
> > to adjust the program info in the stream, have the issue.
> > 
> > The second patch (in ResetReal) is going to be all
> > about timing and specific configurations.  I would not
> > be surprised that the timing might be impacted on
> > choices such as combined and separate BE/FE
> > systems.
> > 
> > Arguably in both cases the mythtv code should be
> > defensive against referring to a non-existent element
> > in a vector (gcc is arguably helping one write better
> > code to avoid falling into a later trap).
> 
> I agree completely.  MythTV should be robust in the face of errors. 
> I've been trying to catch trac while its up to grab your patches.  If
> you would email them directly to me, I'll commit them tonight.
> 
> David
> 
> _______________________________________________
> mythtv-dev mailing list
> mythtv-dev at mythtv.org
> http://lists.mythtv.org/mailman/listinfo/mythtv-dev
> http://wiki.mythtv.org/Mailing_List_etiquette
> MythTV Forums: https://forum.mythtv.org
> _______________________________________________
> mythtv-dev mailing list
> mythtv-dev at mythtv.org
> http://lists.mythtv.org/mailman/listinfo/mythtv-dev
> http://wiki.mythtv.org/Mailing_List_etiquette
> MythTV Forums: https://forum.mythtv.org