Re: [Freevo-devel] Re: Support for Hardware Media Center Extenders.
On 4/30/06, Dirk Meyer <[EMAIL PROTECTED]> wrote: Jared Kells wrote: > I am writing to see if anyone knows of any work done on an open source > implementation of Microsoft's MCX protocol. Not that I know of. > For those that don't know Media Center Extenders are network devices > that plug into your TV and extend Windows Media Center Edition over a > network. The idea is that you have your Media Center PC in one room > and you have an extender in all the other rooms in your house that > have a TV. I thought this is what uPnP is for. OK, uPnP sucks, but last time I checked Microsoft was supporting it. But is would be great to know that my Xbox 360 or SPS 3 were able to stream the media off of a freevo box. I don't think this should be shouldered by freevo, as these devices should come with media players and are build from the 2 most successful GUI designers int he world right? Does anyone know if there are ways to do this though? Plsy my avi's or dvb streams on these next gen devices? Are there any good web pages showing the archtecture plans or anything along those lines? Mick --- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid0709&bid&3057&dat1642 ___ Freevo-devel mailing list Freevo-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freevo-devel
Re: [Freevo-devel] Re: kaa.ipc and step() problems
On Sun, 2006-04-30 at 17:43 +0200, Dirk Meyer wrote: > > I'm not sure either. AFAIK ipc doesn't make any circular refs. But if > > we can find out where, I can try to fix ipc to use weakrefs in the > > appropriate places. > > I now use weakref to connect, maybe it is gone. The strange part is > the query, do you cache something in kaa.ipc? The webserver used query > once, but has no reference to it. If we hold an IPC reference to some object on the remote end, the IPCChannel object on the remote end will hold a reference to that object to make sure it's alive as long as we have a reference to it. When the object goes away on the our side, or if the socket disconnects, the remote IPCChannel will drop reference to that object allowing it to be destroyed if necessary. Keep in mind that in kaa.ipc, client/server just means whoever is listening and whoever is connecting. After that there's really no difference. So the client can hold references to objects on the server and the server can hold references to objects on the client. On either side, once a connection is established, an IPCChannel object is created and that object holds references to all objects it has proxied to the other side. If an IPCProxy object isn't getting deallocated properly, then it means it won't properly decrease the refcount on the other side. This means the IPCChannel will hold onto that object forever or until the ipc connection is dropped. > I did not know that __ipc_async exists. How quickly we forget. :) You were the one who asked for this feature, and so I added it. In fact if you search the list archives you'll see code you produced that uses this feature. :) > I hope you're getting better. Yes, I'm starting to feel much better now. The worst of it was on Thursday. Man, what a bug that was. Jason. --- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 ___ Freevo-devel mailing list Freevo-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freevo-devel
Re: [Freevo-devel] Re: kaa.metadata length always int
On Sun, 2006-04-30 at 17:36 +0200, Dirk Meyer wrote: > I don't remeber, I guess I did not want to see a length of 6547.003246 > seconds in Freevo. IMHO a length in seconds is what we need. Ok, but shouldn't freevo do that? kaa.metadata should provide as much info as it can. It should be up to the caller to decide what to do with it. So I don't think kaa.metadata should be dropping precision. Jason. --- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 ___ Freevo-devel mailing list Freevo-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freevo-devel
[Freevo-devel] Re: kaa.ipc and step() problems
Jason Tackaberry wrote: > On Sat, 2006-04-29 at 19:01 +0200, Dirk Meyer wrote: >> | # Update timestamp on timer before calling the callback to >> | # prevent infinite recursion in case the callback calls >> | # step(). >> | __timers[ i ] = ( interval, notifier.millisecs(), callback ) > > IIRC this was something I added to notifier to work around the recursion > problem you're describing. I guess it didn't fully fix it. See the private mail about that. > Do you think you can reduce this to a simple test case that reproduces > the problem? No. It happens most of the time with the webserver, but I can't reproduce it with a small test app. >> Now to kaa.ipc: using step() is bad. I know step() is a nice feature >> but it could result in recursion. One time I had a crash that logging >> found a recursion and the stack only showed a view lines of code. My >> guess is that we had at least 20 steps in steps. Freevo does not use >> step(), only kaa.ipc does. > > It's very convenient to be able to do synchronous calls. I think this > problem could be resolved by removing step() from kaa.ipc and instead > doing its own select/handle loop. This means other timers won't fire > while the synchronous ipc call is blocking, so it will prevent any timer > recursion. I guess that makes it more important that the call complete > quickly; we could reduce the default timeout value for synchronous > calls. As I wrote before, bad idea because we may need the timer. >> that this is a huge problem. First of all, the remote object has a >> __del__ function (every ipc object has one) and this makes it very >> easy to create circular references. I added a gc() call in the freevo >> main loop and the webserver shows this in the log file: > > Well, more accurately, the existence of __del__ in IPCProxy doesn't make > it easier to create circular references. The circular refs are either > there or they aren't. The existence of __del__ prevents the gc from > cleaning up cyclical refs on its own, though. That's what I meant. I create circular refrences all the time (I guess I should start using the weak variants) but I call gc() from time to time to clean up and I can't do that with circular __del__ functions. >> | Unable to free >> | Unable to free > 0xb76a89ec>> >> | Unable to free > | Unable to free > > >> I have no idea why this happens, it seems to start when the guide is >> updating itself. > > I'm not sure either. AFAIK ipc doesn't make any circular refs. But if > we can find out where, I can try to fix ipc to use weakrefs in the > appropriate places. I now use weakref to connect, maybe it is gone. The strange part is the query, do you cache something in kaa.ipc? The webserver used query once, but has no reference to it. >> To work around this problem, kaa.beacon tries not to use kaa.ipc the >> way Jason designed it: I always send the whole objects to the other >> side and don't wait for answers. I provided a callback function once >> to get answers. This works without using step() during runtime (only >> on connect). So maybe we should redesign kaa.ipc to use callbacks for >> return values to avoid step() in the future. Jason: what do you think? > > Well, kaa.ipc already supports async invocation: > > def handle_remote_meth_return(value): > print "Remote method returned", value > remote_object.meth(__ipc_async = handle_remote_meth_return) I did not know that __ipc_async exists. > P.S. Sorry if I'm not making much sense -- still fighting that flu. I hope you're getting better. Dischi -- If you can't beat your computer at chess, try kickboxing. pgpqge8whUcmE.pgp Description: PGP signature
[Freevo-devel] Re: beacon and excessive stating
Jason Tackaberry wrote: > On Wed, 2006-04-26 at 10:41 +0200, Dirk Meyer wrote: >> > stat the directory and not all the regular files underneath it. It only >> > needs to stat all the regular files if the mtime on the dir has changed. >> >> No > > Right, right. Please ignore the man behind the curtain. > > I was thinking of listdir(), which can avoid if the mtime on the dir > hasn't changed. Do you already do that? No, because I don't store the results of a listdir somewhere. In the db I only have db objects and they are very similar but different in usage. But as you wrote, listdir() is fast, stat takes time and we still need that. Dischi -- Hi! Dave's answering machine is broken. This is his refrigerator. Please speak very slowly, and I'll stick your message to myself with one of these magnets. pgpF5r3nGc6xb.pgp Description: PGP signature
[Freevo-devel] Re: kaa.metadata length always int
Jason Tackaberry wrote: > In kaa.metadata: > > def correct_data(self): > """ > correct length to be an int > """ > MediaInfo.correct_data(self) > if not self['length'] and len(self.video) and self.video[0]['length']: > self['length'] = self.video[0]['length'] > for container in [ self ] + self.video + self.audio: > if container['length']: > container['length'] = int(container['length']) > > How come? What's wrong with length being float? I don't remeber, I guess I did not want to see a length of 6547.003246 seconds in Freevo. IMHO a length in seconds is what we need. Dischi -- Smith & Wesson: The original point and click interface. pgpLvi0gJglqM.pgp Description: PGP signature
[Freevo-devel] Re: Support for Hardware Media Center Extenders.
Jared Kells wrote: > I am writing to see if anyone knows of any work done on an open source > implementation of Microsoft's MCX protocol. Not that I know of. > For those that don't know Media Center Extenders are network devices > that plug into your TV and extend Windows Media Center Edition over a > network. The idea is that you have your Media Center PC in one room > and you have an extender in all the other rooms in your house that > have a TV. I thought this is what uPnP is for. OK, uPnP sucks, but last time I checked Microsoft was supporting it. > I think Microsofts products will push media PC's into the mainstream > and it would be great if we could support all the 3rd party hardware > extenders that will hit the market under Linux. > > The XBOX 360 can act as a media center extender. And personally I > would like to move my Freevo pc out of the lounge room and just have > the XBOX extend it. You can use uPnP to do that. > Apparantly the MCX protocol is a cutdown version of Remote desktop > protocol with a seperate UDP connection to stream the A/V. > Remote Desktop Server For *Nix > http://xrdp.sourceforge.net/ Remote desktop? OK, that part will never be part of Freevo. This is total overkill. I also to support uPnP in Freevo 2.0 but I won't spend any time in supporting MCX. Dischi -- It might look like I'm doing nothing, but at the cellular level I'm really quite busy. pgp3hIgbdDOxP.pgp Description: PGP signature
