[optip]

i've moved the nntp communication stuff and deEnc stuff to use file pointers instead of doing anything in RAM, so i am almost ready to set up the functionality for multithreading... i've still got some issues however!

there is some curruption in the yDecoded content that i am downloading & decoding... with mp3s, this results in little skips that you can here. the mpg123 system is also complaining (at the same time as these skips) that it can't rewind by X bits... if i do a diff on the mp3 file; compiring the decoded content i am getting to the same file downloaded through newspro, there are a few differences alright... i spent most of yesterday trying to debug this but all i know so far is that i think my decoder subroutine is ok!.. doh!

gonna check next that the downloaded encoded content is correct and the corruption isn't introduced before the decoder gets a chance to do its work! if the answer doesn't become obvious to me within the next hour or two of looking at it, i'm going to skip it for now and revisit it later, while i impliment the multi threaded-ness.

i figured also that it's not really strictly necessary to use multi-threaded nntp streams for the reasons i had originally thought... the yEnc'd content can be decoded on the fly pretty easily without this... it was mentioned however that some free/isp nntp services give you 4 connections with each of the connection speed capped to a certain bandwidth... i will therefore impliment the threading functionality anyway to make sure we can get the fattest data stream possible, and to make sure that as a result, streaming will work for the most people....

will post when i have more news!

Patrick.

[nate12o6]

optip your the man!

[C-Quel]

jolly good stuff...

[Ph03n1x]

It's been a while since I've been left speechless...
- Amazing work!

[officechris]

Simply amazing, my dreams have finally come true! This will truly revolutionize the streaming media industry!

[nate12o6]

I honestly dont think i would have to pay for cable anymore.
NZB support + newzbin = greatest IPTV plan every.

PS. Most isps supply newsgroup access for free!

[optip]

well... i certainly won't be throwing my satellite out! i like my high-def, and football too much for that!!

i've really been working on the boring house keeping stuff to get the memory usage to a minimum... i had been caching the nzb file contents in a static char[][] variable but that's not very efficient... gonna just use (i think) a CDirectory and cache nzb contents (i.e. the info gathered from connecting to nntp for each file in the nzb to make sure we have correct filenames & sizes) to disk so it doesn't have to be re-read when you move between nzbs, and between the CDirectory and CFile type classes.

i still haven't solved (haven't really tried since last weekend either!) the curruption problem with decoded content..

Im going to try to impliment some threads tonight.. never done that in c++ before so should be fun!

[nate12o6]

Yea i hear you. I figured i could get Fox and CBS over the air HD but now that you mention it i wont be getting ESPN and TNT for the nba playoffs. I guess i will be holding on to my dish network as well. But still will be sweet to get nzb support!!! hehe

I was messing around with nzbplayer for the pc. And i just cant wait for this to be available on xbmc.

Also will be nice when linksbox is fully integrated.

[optip]

gonna just use (i think) a CDirectory and cache nzb contents!

oops... i mean - a CFileItemList - not a CDirectory!

[Peteo]

This sounds awesome, I have a 250 gig hd in my xbox waiting for something just like this. Right now I just stream from my computer, but with this I can just leave on my xbox and have it grab stuff right to its hard drive!
If you can get NZB RSS feed support it would be AWESOME!


Heres a link to a newzbin RSS feed for the daily show

http://v3.newzbin.com/search/query/?q=Th...0&feed=rss

Thanks!

[optip]

This sounds awesome, I have a 250 gig hd in my xbox waiting for something just like this. Right now I just stream from my computer, but with this I can just leave on my xbox and have it grab stuff right to its hard drive!

Hi Peteo... actually; this really is a streaming solution and doesn't save anything to your hard drive (except some small temp files)... the idea is that you stream media straight from usenet without saving it. TBH.. not saving stuff is part of the beauty of this for me!

Technically, it would not be difficult to add this functionality.. you could for example configure this so when it is streaming content, it is also saving it somewhere for keeping... this is slightly outside of the core focus of XBMC (from a quick chat i had with cptspiff) as a media player however so won't be a feature from the beginning.

It does create new issues however like -- file management - where to store things... partially watched things(=partially downloaded things) (still keep files?).. different begaviours for handling music and video content.. differerent save locations/creating dedicated album directories, etc,etc..

could be good for a 1.1/1.2 release tho!

[optip]

update... i've really not had much time to work no this this week so i'veonly been reviewing my code so far for ennefficiencies this week because that's all the time i've been able to give... there are no major technical blocks to having this working however.... at this stage though, it could be early next week before i can release anything
Patrick.

[nate12o6]

hows the memory holding up? That was one of my concerns that the 64mb of ram would max out.

[optip]

hi,

i think the memory will be ok... i download everything straight into a file so, content is downloaded straight into a file called z:\temp\encoded.1.tmp (where 1 is the thread id).. when its downloaded, it's decoded into z:\temp\decoded.1.tmp - and the player plays by fread'ing from this decoded.1.tmp file... i wrote a new ydecode procedure that decodeds straight from one file pointer to another - byte by byte so no major mem usage there either. because all the data is kept in files, it shouldn't take much more memory to have lots of threads given that they aren't really storing any content in RAM.

one issue with this is that there is potentially a lot of disk churn with all the concurrent reading and writing... i think it shoud be ok and so am ignoring this as an issue for now... if anybody wants to tell me that they know that is a real problem however, it's probably better to address it now then have lots of ppl complaining of dead hard disks later!!

where i do have a problem is that i was storing a lot of nzb content and related info statically in ram.. i've been working towards changing this.

i've been basing what i'm working towards in terms of memory usage by compairing playing a file from a smb share, with playing a file on a smb share from inside a rar file... if i can get anywhere close to that, i'll be very happy! All of that code seems really tight!

[jmarshall]

Can you decode as you recieve the data? Writing just to one file per thread will be quite a bit more efficient than write/read/write