Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
*/
-
-/*
-
-#ifndef WIN32
- pthread_mutex_lock(&boxLock);
-#else
- WaitForSingleObject(boxLock, INFINITE);
-#endif
-
-
-#ifndef WIN32
- pthread_mutex_unlock(&boxLock);
-#else
- ReleaseMutex(boxLock);
-#endif
-
-
-
-
-*/
-
-
-
-
#include "boxstack.h"
#include "command.h"
FYI
-Timers ... deprecated. Maybe.
-
-This whole thing will be replaced with a timed-message idea. It will be possible
-to send yourself (or whoever) a message with a delay, or delivery time. The message
-will be handed to Command as usual, but command will do the right thing. The messages
-will be delivered to the recipient _with the gui mutex locked_, meaning updates can
-be done there and then in the message handler.
-
-Good points:
-* Cuts down on code lines
-* Most (all?) timercall()s eventually send a message to command in order to
- do something within The Big Mutex. This makes it easier and simpler code wise
-* Gets rid of Timers.
-* Hopefully gets rid of most postMessageFromOuterSpace calls
-
-Bad points:
-* Timers become gui only features. Solve this with a MessageReceiver interface and
- have command deliver messages straight to the recipients rather than through BoxStack.
-* Timer delivery accuracy becomes dependant on everything that uses The Big Mutex.
- It will become more important to not block The Big Mutex.
-* Cancelling timers... hmm
-
-If you have any comments about the new design, like, "It's just as flawed as the old one",
-then I'd appreciate hearing it before I start writing it all :)
+Fixed:
+
+The main problem was that timers only seemed to launch messages which went into The Big Mutex.
+This has been fixed a different way by implementing locking in BoxStack - meaning timercalls
+can now draw and update their displays without locking The Big Mutex. Problem solved. I think
+the whole program might move more towards classes keeping more mutexes and rely less on The
+Big Mutex.
+
+
+
+> Timers ... deprecated. Maybe.
+
+> This whole thing will be replaced with a timed-message idea. It will be possible
+> to send yourself (or whoever) a message with a delay, or delivery time. The message
+> will be handed to Command as usual, but command will do the right thing. The messages
+> will be delivered to the recipient _with the gui mutex locked_, meaning updates can
+> be done there and then in the message handler.
+
+> Good points:
+> * Cuts down on code lines
+> * Most (all?) timercall()s eventually send a message to command in order to
+> do something within The Big Mutex. This makes it easier and simpler code wise
+> * Gets rid of Timers.
+> * Hopefully gets rid of most postMessageFromOuterSpace calls
+
+> Bad points:
+> * Timers become gui only features. Solve this with a MessageReceiver interface and
+> have command deliver messages straight to the recipients rather than through BoxStack.
+> * Timer delivery accuracy becomes dependant on everything that uses The Big Mutex.
+> It will become more important to not block The Big Mutex.
+> * Cancelling timers... hmm
+
+> If you have any comments about the new design, like, "It's just as flawed as the old one",
+> then I'd appreciate hearing it before I start writing it all :)
*/
int audioChannelListSize = acl.size();
for(int i = 0; i < audioChannelListSize; i++)
{
- delete acl[i]; // FIXME memory leak - nobody is deleting audio channel name?
+ // FIXME memory leak - nobody is deleting audio channel name? // try:
+ delete[] acl[i]->name;
+ Log::getInstance()->log("VAudioSelector", Log::DEBUG, "Deleted char[] on close");
+ delete acl[i];
}
acl.clear();
if (chanList) chan = (Channel*)sl.getCurrentOptionData();
if (chan == NULL) return 2;
-// if (chan->type == VDR::VIDEO)
-// {
- VVideoLiveTV* v = new VVideoLiveTV(chanList, chan->number, this);
- boxstack->add(v);
- v->go();
-/*
- }
- else
- {
- VVideoLive* v = new VVideoLive(chanList, chan->type, this);
- v->draw();
- boxstack->add(v);
- boxstack->update(v);
- v->channelChange(VVideoLive::NUMBER, chan->number);
- }
-*/
+ VVideoLiveTV* v = new VVideoLiveTV(chanList, chan->number, this);
+ boxstack->add(v);
+ v->go();
+
return 2;
}
case Remote::BACK:
selectedServer = -1;
VServerSelect* vs = new VServerSelect(servers, this);
vs->draw();
- boxstack->add(vs); // FIXME - do this better - perhaps post message to Command
- // Otherwise it will be using BoxStack without the Command mutex locked
+ boxstack->add(vs);
boxstack->update(vs);
threadLock();
return chanList;
}
-
-int VDR::streamChannel(ULONG number)
-{
- // FIXME radio
- return 0;
-}
-
int VDR::streamChannel(ULONG number, StreamReceiver* tstreamReceiver)
{
VDR_RequestPacket vrp;
int deleteTimer(RecTimer* delTimer);
ChannelList* getChannelsList(ULONG type);
int streamChannel(ULONG number, StreamReceiver*);
- int streamChannel(ULONG number);
void getChannelPids(Channel* channel);
UCHAR* getBlock(ULLONG position, UINT maxAmount, UINT* amountReceived);
//get image blocks separate - we can do this in parallel
{
Log::getInstance()->log("VRadioRec", Log::DEBUG, "Pre stopPlay");
- // FIXME work out a better soln for this
- // Fix a problem to do with thread sync here
- // because the bar gets a timer every 0.2s and it seems to take up to 0.1s,
- // (or maybe just the wrong thread being selected?) for the main loop to lock and process
- // the video stop message it is possible for a bar message to stack up after a stop message
- // when the bar message is finally processed the prog crashes because this is deleted by then
removeBar();
- //
-
player->stop();
vdr->stopStreaming();
delete player;
{
Log::getInstance()->log("VVideoRec", Log::DEBUG, "Pre stopPlay");
- // FIXME work out a better soln for this
- // Fix a problem to do with thread sync here
- // because the bar gets a timer every 0.2s and it seems to take up to 0.1s,
- // (or maybe just the wrong thread being selected?) for the main loop to lock and process
- // the video stop message it is possible for a bar message to stack up after a stop message
- // when the bar message is finally processed the prog crashes because this is deleted by then
removeBar();
- //
-
player->stop();
vdr->stopStreaming();
delete player;
if (area.w < 5) return;
if (area.h < 5) return;
- printf("progress bar: %u\n", percent);
-
// Hmm, can't draw two boxes because should not paint on areas
// not needing it - this class does not know the background colour
projects / vompclient-marten.git / commitdiff