Opened 14 years ago

Closed 14 years ago

Last modified 14 years ago

#8872 closed defect (fixed)

Unable to access MythWeb when streaming UPNP

Reported by: ccarter0@… Owned by: beirdo
Priority: trivial Milestone: 0.24
Component: MythTV - UPnP Version: 0.23-fixes
Severity: low Keywords:
Cc: Ticket locked: yes

Description

I'm using Mythdora 12 a fresh install. I use myth as my backend and dlink dsm-520 clients. When I play a recording with the dlink I can't access mythweb. Also I can only play one dsm-520 unless I restart the mythbackend deamon then I can only play two.

Attachments (1)

mythversion.txt (766 bytes) - added by ccarter0@… 14 years ago.
Mythbackend --version

Download all attachments as: .zip

Change History (23)

comment:1 Changed 14 years ago by robertm

Owner: changed from dblain to beirdo
Priority: blockertrivial
Severity: mediumlow
Status: newassigned

Please read the ticket howto, do not set priorities.

comment:2 Changed 14 years ago by beirdo

Status: assignedinfoneeded

Please attach the output of 'mythbackend --version' so I have a clear idea of what version you are running.

comment:3 in reply to:  description Changed 14 years ago by dan@…

Status: infoneededassigned

Replying to ccarter0@…:

I'm using Mythdora 12 a fresh install. I use myth as my backend and dlink dsm-520 clients. When I play a recording with the dlink I can't access mythweb. Also I can only play one dsm-520 unless I restart the mythbackend deamon then I can only play two.

Similiar here with fairly recent install of mythbuntu10.04 and autofixes through .23.1. mythweb will not show recorded programs during a upnp stream, but will show upcoming recordings. Resolves when upnp stream completely terminated. Also- can only do upnp streams to clients all over the house, but only at a time.

comment:4 Changed 14 years ago by robertm

Status: assignedinfoneeded

Information requested *not* provided, please don't set as info provided.

comment:5 Changed 14 years ago by dan@…

Status: infoneededassigned

MythTV Version : 26057 MythTV Branch : branches/release-0-23-fixes Network Protocol : 23056 Library API : 0.23.1.201000710-1 QT Version : 4.6.2

comment:6 Changed 14 years ago by dan@…

okay- I cant type. UPNP streams for me to many different clients, but only to one client at a time. During any upnp stream- mythweb will not show recorded programs, but will show upcoming recordings.

comment:7 Changed 14 years ago by beirdo

OK, thanks. I will look into this tonight some, and will see if it acts the same with trunk as well. If so, this is something that needs some serious investigation. I only have one UPnP client to test with, essentially, but I am expecting I'll find this is two symptoms of the same core issue.

Changed 14 years ago by ccarter0@…

Attachment: mythversion.txt added

Mythbackend --version

comment:8 Changed 14 years ago by beirdo

Status: assignedinfoneeded

Thank you.

After several hours of messing with it, and tweaking... And having it only fail a couple times, but not easily repeatable, I may have stumbled across the issue.

The ThreadPool? for the HTTP service on :6544 has a default maximum of 5 threads. It is completely plausible that you may be running out of threads. Luckily, there's a db setting for that.

Try setting "ThreadPool?/HTTP/Max" to a value of 10 (doubling it), and then trying again.

mysql -umythtv -p mythconverg   (I'm assuming the default mysql user/password here)
> INSERT INTO settings (value, data, hostname) VALUES ('ThreadPool/HTTP/Max', '10', NULL);
> quit

If this fixes the issue, I will add a bit of logging to where we detect worker thread exhaustion, and we can consider increasing the default maximum.

Please let us know if this helps.

Version 0, edited 14 years ago by beirdo (next)

comment:9 Changed 14 years ago by ccarter0@…

Status: infoneededassigned

I have updated the setting and played 3 UPNP on my DSM-520, but was unable to use mythweb. So I updated it from 10 to 15. All worked. 3 UPNP steams with DLINK DSM-520 and mythweb working. I thank you for you quick response and all you countless hours of work on the myth system.

comment:10 Changed 14 years ago by beirdo

Resolution: fixed
Status: assignedclosed

comment:11 Changed 14 years ago by beirdo

(In [26182]) Add a bit of logging into the threadpool code to indicate startup values and scream when the pool gets exhausted and we have to refuse work. This should help diagnose when someone will need to increase their pool size.

We should look into better dynamical scaling of the pool in the future if possible.

Refs #8872

comment:12 Changed 14 years ago by beirdo

Milestone: unknown0.24

comment:13 Changed 14 years ago by dan@…

Not much changed for me. If upnp stream is playing, then most of mythweb works but not the backend status tab. It eventually times out with the following..

Warning at /usr/share/mythtv/mythweb/modules/status/handler.php, line 35: file_get_contents(http://192.168.1.97:6544): failed to open stream: HTTP request failed!

Did I get it wrong? My shell session looks like...

mysql mythconverg --user=mythtv --password=somepassword

mysql> INSERT INTO settings (value, data, hostname) VALUES ('ThreadPool?/HTTP/Max', '20', NULL); Query OK, 1 row affected (0.04 sec)

mysql> quit Bye

And sad for me is that upnp can play in one room or the other, but never at the same time. Could this be an issue with upnp or my router, or the threadpool thing?

comment:14 Changed 14 years ago by beirdo

If you didn't restart the backend after that change, you need to. Otherwise that setting is not read.

comment:15 Changed 14 years ago by dan@…

Guess its not the routers fault regarding two upnp streams at once. After all, I can stream two at once if each stream originates from a different server. One upnp can come from my old mythtv .21 server to one client, and one from my mythbuntu .23.1 to a different client. But seems no mythtv backend can stream more that one upnp at a time, though there seems to be enough bandwidth to accomplish it.

While streaming, mythweb will show recorded programs, but not backend status. Backend status resumes when the stream is fully stopped, not just paused.

comment:16 Changed 14 years ago by ccarter0@…

I think we still have a problem making the change worked after I restart the mythbackend but I came home last night after a day of the backend recording and no joy. I did restart the backend (had three programs recording). So I trie again no recording just playing one UPNP and they mythweb will no response. I restart the mythbackend and all work again. So something is not freeing the task,thread...etc.

comment:17 Changed 14 years ago by dan@…

I'm finally catching up. Yes- after restart (actually reboot) I can for the first time ever have 2 UPNP streams from one backend to two different clients. Horray! And as per the original issue, I can use all tabs in mythweb, (including Backend Status), while both streams are active! Huge progress on this and I agree that INSERT INTO settings (value, data, hostname) VALUES ('ThreadPool?/HTTP/Max', '15', NULL);, from above is much more effective after restarting the backend. <smile>

I will run more tests after running other frontends, recording jobs, and user jobs to see if this fix is persistent or not as ccarter0 found it may not be.

comment:18 Changed 14 years ago by dan@…

I have ran a few user jobs, made two recordings, and at first could still launch two upnp streams simultaneously, and get fast response in all tabs in mythweb. BUT, after ending the upnp streams, and nothing else running, mythweb no longer responds properly as before, even if no upnp streams are running.

comment:19 Changed 14 years ago by beirdo

Version: Unspecified0.23-fixes

comment:20 Changed 14 years ago by beirdo

I can not reproduce this and I can see no reason why this would happen other than that maybe you need to even further enlarge your ThreadPool? maximum thread count.

  • try increasing the setting to 20 or 25 (remembering to restart the backend after!)
  • Any chance you could use trunk to see if it is still doing this?
  • If you can't test with trunk and you are still seeing issues, I propose we look at this again after 0.24 release.

comment:21 Changed 14 years ago by Tomi Orava <tomi.orava@…>

I just happened to check the latest commit you did to threadpool.cpp and noticed that just above the line you added:

VERBOSE(VB_IMPORTANT, QString("ThreadPool:%1: thread pool exhausted (max %2 threads)") .arg(m_sName) .arg(m_nMaxThreadCount));

There is a code block originally made by Janne Grunau, that I've seen all over the mythtv code and it's completely wrong! ie:

Around line 392 in trunk there is this code:

QMutex mutex;
mutex.lock();

if (m_threadAvail.wait( &mutex, 5000 ) == false )
{
    VERBOSE(VB_IMPORTANT, QString("ThreadPool:%1: thread pool exhausted (max %2 threads)") .arg(m_sName) .arg(m_nMaxThreadCount));
    return( NULL );     // timeout exceeded.
}

The thing is you just can't invent a temporary mutex for the condition wait and condition signal calls. Because the mutex is completely bogus and the threads sending the condition signals are not locking the very same mutex and also because there is no mutual signal variable between the signalling threads and the waiter it can happen very easily that the condition signal has already been sent _before_ the waiter thread calls the condition wait ---> the condition wait will eventually exit with timeout exceeded ie NULL value.

All of this is very easy to fix, make all the signalling threads lock the mutex, set a mutual signalling variable (bool) to true, unlock the mutex and call condition.signal. The waiter then has to lock the common mutex, check if the mutual variable has been set to true --> a signal has been delivered beforehand, if true, set the variable to false, unlock the mutex and return with success etc. Otherwise the waiter just has to call the wait and if it receives a signal it just has to disable the signalling variable, unlock the mutex and return accordingly.

I don't know it this actually helps in your ticket, but for sure this block contains a design bug.

comment:22 Changed 14 years ago by beirdo

Ticket locked: set

Added a reference in #8854 which is the same issue elsewhere.

I'm locking this ticket. If there's a reoccurance, please open a new ticket, this one is growing unmanagable.

Last edited 14 years ago by beirdo (previous) (diff)
Note: See TracTickets for help on using tickets.