+- Kodi Community Forum (https://forum.kodi.tv)
+-- Forum: Support (https://forum.kodi.tv/forumdisplay.php?fid=33)
+--- Forum: General Support (https://forum.kodi.tv/forumdisplay.php?fid=111)
+---- Forum: Windows (https://forum.kodi.tv/forumdisplay.php?fid=59)
+---- Thread: [WINDOWS] Internal Directshow Based Player [NO LONGER DEVELOPED] (/showthread.php?tid=61355)
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
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
- furii - 2010-03-28
uncertainty Wrote:Just upgraded to rev 28917 on Win7 and I'm showing a high cpu load for any type of material including xvid. This occurs using either dsplayer or dvdplayer and its about a 50% jump on my cpu compared to previous releases. I did read others recommended to disable "Allow Programs On This System To Control XBMC" under Network but that had no effect. Before I start posting logs can anyone else confirm high cpu usage with 28917 no matter the media type or player?
thanks
i've noticed high loads on 28916 off the main trunk so it's probably a problem there. if you check taskmanager you'll notice you have high loads outside of playing videos as well. for me, this generally happens after browsing around the movie or tv library.
- uncertainty - 2010-03-28
furii Wrote:i've noticed high loads on 28916 off the main trunk so it's probably a problem there. if you check taskmanager you'll notice you have high loads outside of playing videos as well. for me, this generally happens after browsing around the movie or tv library.
Yep agree fully and wanted others to confirm....Definately not a dsplayer issue and hopefully future trunks correct it soon.
- christoofar - 2010-03-28
uncertainty Wrote:Just upgraded to rev 28917 on Win7 and I'm showing a high cpu load for any type of material including xvid. This occurs using either dsplayer or dvdplayer and its about a 50% jump on my cpu compared to previous releases. I did read others recommended to disable "Allow Programs On This System To Control XBMC" under Network but that had no effect. Can anyone else confirm high cpu usage with 28917 no matter the media type or player?
thanks
Edit: Others confirm the main trunk 28916 is the cause and NOT dsplayer.
argh..think I'm gonna go back to what I had running before.
Sure are a lot of issues with these latest (not dsplayer) svn builds
- steelman1991 - 2010-03-28
christoofar Wrote:argh..think I'm gonna go back to what I had running before.
Sure are a lot of issues with these latest (not dsplayer) svn builds
Wasn't that why the xbmc team requested that devs stop using them until after the merge. If so why should anyone (not getting at you in particular christoofar - just re-read my response and it seemed that way) be surprised when things go wrong with the trunk that affects the dsplayer branch. As far as I know this is only place where you can obtain a current svn without compiling yourself.
Why complain when we know that these builds are likely to be borked anyway, if the xbmc team don't deem them to be stable enough to release.
- christoofar - 2010-03-28
steelman1991 Wrote:Wasn't that why the xbmc team requested that devs stop using them until after the merge. If so why should anyone (not getting at you in particular christoofar - just re-read my response and it seemed that way) be surprised when things go wrong with the trunk that affects the dsplayer branch. As far as I know this is only place where you can obtain a current svn without compiling yourself.
Why complain when we know that these builds are likely to be borked anyway, if the xbmc team don't deem them to be stable enough to release.
Perhaps then development for dsplayer should stop also?
I assumed Seb & tiben wanted people to use them . This build was listed as "working with XP", so that is why I gave it a try.
- steelman1991 - 2010-03-28
christoofar Wrote:Perhaps then development for dsplayer should stop also?
I assumed Seb & tiben wanted people to use them . This build was listed as "working with XP", so that is why I gave it a try.
I'm sure they do. I just found/find it strange that development continues with a branch of coding which is so obviously affected by the trunk, but that's Tiben and Sebs perogative, there was a request not to produce any svn's until after the merge not a ban and they have decided that the dev work on the branch is obviously worth the hassle of an unstable trunk application.
- christoofar - 2010-03-28
Am installing 28016 that the Real Joe recommended, & then will just wait till the main development starts up again and they can get the new bugs worked out .
- uncertainty - 2010-03-29
christoofar Wrote:Am installing 28016 that the Real Joe recommended, & then will just wait till the main development starts up again and they can get the new bugs worked out .
BTW thats ironic because the reason I tried to upgrade to a newer rev was that milkdrop does not work in 28016...
- SlaveUnit - 2010-03-29
They are still working on their DSPlayer option because the work they are doing show not be effected (much) by all the other things the devs are working on. So I see no reason to wait until the devs are done with the main trunk to continue work with the.
I know I am guilty of this bringing up the high cpu and large log usage but we really shouldnt be bringing up any issues outside of the DSPlayer itself. It should be pretty obvious by now that it is the main branch that is causing the issue.
- chunk1982 - 2010-03-29
SlaveUnit Wrote:They are still working on their DSPlayer option because the work they are doing show not be effected (much) by all the other things the devs are working on. So I see no reason to wait until the devs are done with the main trunk to continue work with the.
I know I am guilty of this bringing up the high cpu and large log usage but we really shouldnt be bringing up any issues outside of the DSPlayer itself. It should be pretty obvious by now that it is the main branch that is causing the issue.
could not agree more beside is this not the risk we take "living life on the knife edge" with these types of builds!?
if you dont like the risks or the crappy out come of a couple builds dont download and test these builds
go and download the stable one from here http://xbmc.org/download/ its not hard
- christoofar - 2010-03-29
uncertainty Wrote:BTW thats ironic because the reason I tried to upgrade to a newer rev was that milkdrop does not work in 28016...
Wellll..I'm guilty of the same thing..wanting to get back milkdrop:p
- christoofar - 2010-03-29
chunk1982 Wrote:could not agree more beside is this not the risk we take "living life on the knife edge" with these types of builds!?
if you dont like the risks or the crappy out come of a couple builds dont download and test these builds
go and download the stable one from here http://xbmc.org/download/ its not hard
Then perhaps there should be a pre-set group of beta testers to work with Seb & tiben off line.
Lots of people come here (like myself) & see this:
Change log:
- 28/03/2010 - Build 28917 :
* fixed playback on Windows XP
* Merged from trunk to r28891
* 03/23/2010 - Build 28772 :
o Scrappers & vizu are back
And then it really doesn't work , wether it is dsplayer related or not.
Either way, it doesn't work...:p
- SlaveUnit - 2010-03-29
christoofar Wrote:Then perhaps there should be a pre-set group of beta testers to work with Seb & tiben off line.
Lots of people come here (like myself) & see this:
Change log:
- 28/03/2010 - Build 28917 :
* fixed playback on Windows XP
* Merged from trunk to r28891
* 03/23/2010 - Build 28772 :
o Scrappers & vizu are back
And then it really doesn't work , wether it is dsplayer related or not.
Either way, it doesn't work...:p
LOL we are the beta testers. Thats why things are SVN. The only way you can't complain is if you are running a stable build of XBMC...period. Any SVN of any program is just that, a subversion made for testing until it goes alpha, beta, release candidate etc. If you are ever worried about breaking things then you should never run an SVN on your main machine. I have 3 XBMC pcs here. One I care about and is months behind because I dont want to ruin it. One in a bedroom whcih is kinda ruinable and I run XBMC here on my desktop so it can be ruined and I dont care. I always install a build on the work machine before moving it to a machine I care about. Peope in here should do the same.
- chunk1982 - 2010-03-29
christoofar Wrote:Then perhaps there should be a pre-set group of beta testers to work with Seb & tiben off line.
Lots of people come here (like myself) & see this:
Change log:
- 28/03/2010 - Build 28917 :
* fixed playback on Windows XP
* Merged from trunk to r28891
* 03/23/2010 - Build 28772 :
o Scrappers & vizu are back
And then it really doesn't work , wether it is dsplayer related or not.
Either way, it doesn't work...:p
due to the amount of hardware variations from user to user what may have worked for seb and tiben may not infact work for you
i seen people saying that rev 28016 was good but i had total video play back failiure lol thats life what you going to do? WAIT for the next release while smiling and saying thank you
- tiben20 - 2010-03-29
christoofar Wrote:Am installing 28016 that the Real Joe recommended, & then will just wait till the main development starts up again and they can get the new bugs worked out .The vmr9 is back to the 28016 version. It was from far away the best version of it