+- XBMC Community Forum (http://forum.xbmc.org)
+-- Forum: Help and Support (/forumdisplay.php?fid=33)
+--- Forum: Add-ons Help and Support (/forumdisplay.php?fid=27)
+---- Forum: Program Add-ons (/forumdisplay.php?fid=151)
+---- Thread: [RELEASE] Pneumatic (/showthread.php?tid=97657)
Pages: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155
RE: [RELEASE] NZBS.org - Dharma and Pneumatic - Eden - Popeye - 2012-03-23 12:39
(2012-03-23 12:35)BaldJedi Wrote: I have been reading earlier posts about earlier versions not working with apple tv 2 trying to stream over a network with sabnzbd running on another machine.
Has the latest version now sorted this problem? as i am just waiting for an apple tv 2 to be delivered.
No. I don't have a ATV2 so the motivation is not really there and the problem is the way python in XBMC is accessing remote shares. Nothing easy to solve..
RE: [RELEASE] NZBS.org - Dharma and Pneumatic - Eden - BaldJedi - 2012-03-23 13:14
Ok...thanks.
RE: [RELEASE] NZBS.org - Dharma and Pneumatic - Eden - Bstrdsmkr - 2012-03-23 18:22
(2012-03-23 12:08)Popeye Wrote:(2012-03-23 12:04)atmorell Wrote: Maybe we could track the playback by writing position every 10th second to a XML file or similar.
Had that in mind. I'm unsure how XBMC behaves with long searches when the end is missing.. ref: http://mirrors.xbmc.org/docs/python-docs/xbmc.html#Player-seekTime
If you're playing an incomplete file and seek past the downloaded portion, playback will end just like if the file was complete. OnPlaybackEnded() is even called =(
You'll have to calculate the equivalent play time you have downloaded based on the current file size and bitrate, then use min(requestedSeek, maxDownloaded -10) or etc (don't want to get so close to the end that the buffer is going to run out with normal playback). It's not a fun problem to solve.
RE: [RELEASE] NZBS.org - Dharma and Pneumatic - Eden - Popeye - 2012-03-23 18:29
(2012-03-23 18:22)Bstrdsmkr Wrote: It's not a fun problem to solve.
I think a feature is more fun than a bug, like the current "cray-names"
RE: [RELEASE] NZBS.org - Dharma and Pneumatic - Eden - Popeye - 2012-03-23 20:00
(2012-03-23 18:22)Bstrdsmkr Wrote: If you're playing an incomplete file and seek past the downloaded portion, playback will end just like if the file was complete. OnPlaybackEnded() is even called =(
You'll have to calculate the equivalent play time you have downloaded based on the current file size and bitrate, then use min(requestedSeek, maxDownloaded -10) or etc (don't want to get so close to the end that the buffer is going to run out with normal playback). It's not a fun problem to solve.
BTW, thanks for your input. If I register the time the movie start playing and the total size, and later like every 10 seconds register time and size left, there should be a fairly good chance of calculating whats needed to resume...
RE: [RELEASE] NZBS.org - Dharma and Pneumatic - Eden - Bstrdsmkr - 2012-03-23 20:46
I'm doing something similar in 1Channel. I've been experimenting with different ways to do it, here's the simplest I've found so far: https://github.com/bstrdsmkr/1Channel/blob/master/1Channel/playback.py
You can actually see some commented out code where I've messed with using different threads and etc. I used a property of the class object instead of writing to a file because some users were having issues with permissions and etc. As a bonus, it turned out to be noticeably more efficient, about a 3-5% cpu drop on my 3.0ghz dual core. (I think the file writes were getting queued and backing up).
Catching the onSeek() event should let you handle users trying to manually fast forward too far. Thinking about it more, I think you could probably do it by percentage and get close enough. getTotalTime() gives you the number of seconds for a given file size, so from that you can get a good idea of how many seconds you've downloaded. Then you could play with it and give yourself a little margin of error to make sure you don't seek too far.
Re: [RELEASE] NZBS.org - Dharma and Pneumatic - Eden - Popeye - 2012-03-23 21:07
Thank you!! Excellent information and help.
RE: [RELEASE] NZBS.org - Dharma and Pneumatic - Eden - wireman99 - 2012-03-25 18:06
Popeye,
Just a quick update on the "crazy-names, no rar errors".
After several hours of digging around I've come to several conclusions.
1): Doesn't matter the method used to send the nzb to SAB. Whether sent by Pneumatic or having SAB pickup the nzb from a watch folder. The results are the same. Several header names get changed to the short name format (the.name.rar) and the repair Par volumes are always at the top of the queue.
2): Changing the number of connections set in SAB to connect to the Usenet server changes the number of header names changed in the queue. The more connections the more names that are changed.
3): Lastly. After much frustration I switched from using the Newznab plugin, configured to use nzb.su, to the Nzbmatriz plugin. Doing this allowed all nzb's that were failing to work. I suspect it's the way nzb.su is constructing the nzb file.
When I get additional time I'll compare the way the two different nzb's are constructed to see what the difference might be. Not sure if this will help you in dealing with this issue as it's entirely outside of Pneumatic.
Also really like the new speed and eta features you've added. Take care and keep up the good work.
Re: RE: [RELEASE] NZBS.org - Dharma and Pneumatic - Eden - Popeye - 2012-03-25 18:38
(2012-03-25 18:06)wireman99 Wrote: Popeye,
Just a quick update on the "crazy-names, no rar errors".
After several hours of digging around I've come to several conclusions.
1): Doesn't matter the method used to send the nzb to SAB. Whether sent by Pneumatic or having SAB pickup the nzb from a watch folder. The results are the same. Several header names get changed to the short name format (the.name.rar) and the repair Par volumes are always at the top of the queue.
2): Changing the number of connections set in SAB to connect to the Usenet server changes the number of header names changed in the queue. The more connections the more names that are changed.
3): Lastly. After much frustration I switched from using the Newznab plugin, configured to use nzb.su, to the Nzbmatriz plugin. Doing this allowed all nzb's that were failing to work. I suspect it's the way nzb.su is constructing the nzb file.
When I get additional time I'll compare the way the two different nzb's are constructed to see what the difference might be. Not sure if this will help you in dealing with this issue as it's entirely outside of Pneumatic.
Also really like the new speed and eta features you've added. Take care and keep up the good work.
Thanks for the investigation information
I have made the same conclusions and also looked through the SAB source code. 1, is correct. It all depends on the nzb.
2, also correct, the name is resolved once the article is read. Standard is to use the same subject as attachment or use "the.name.rar" in thevsubject , this is what SAB looks for.
3, you are most probaly right, the index sites uses different code to produce the meta information.
I know what to do and will have the code cooking for a few more days until ready.
btw, glad you liked the eta. More in this area soon...
RE: [RELEASE] NZBS.org - Dharma and Pneumatic - Eden - Popeye - 2012-03-25 20:27
Code:
*
, , , , ,
# # # # #
_#_#_#_#_#_
{_` ` ` ` `_}
_{_._._._._._}_
{_ H A P P Y _}
_{_._._._._._._._}_
{_ B I R T H D A Y _}
.---{_._._._._._._._._._}---.
( `"""""""""""""""""""""` )
jgs `~~~~~~~~~~~~~~~~~~~~~~~~~~~`