+- 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] External Player Support Thread (/showthread.php?tid=43511)
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
- moby-uk - 2009-02-10
hobojester Wrote:1) When zoom closes, I see my desktop for about 1-2 seconds. I figure this is completely normal since XBMC is coming back into the foreground.
if you have <hidexbmc>true</hidexbmc> in your advancedsettings then yes, this is normal.
hobojester Wrote:3) There is a 15-45 second delay before the keyboard/remote responds to my up/down/any keys/buttons. When it does respond the 'list' I'm looking at goes away very briefly (1s) so I'm just looking at the XBMC background picture, and then the list comes back exactly where it should be and now I have control.
There's a fair few things that happen after playback ends, though 45 seconds seems like a long time. How long does it take the list to return and be responsive after playback ends in the builtin player? It should be about the same amount of time, though with the builtin player you're looking at probably a black screen or whatever bit of the credits were there when playback ended or you stopped it so it may seem different.
- hobojester - 2009-02-10
moby-uk Wrote:if you have <hidexbmc>true</hidexbmc> in your advancedsettings then yes, this is normal.
There's a fair few things that happen after playback ends, though 45 seconds seems like a long time. How long does it take the list to return and be responsive after playback ends in the builtin player? It should be about the same amount of time, though with the builtin player you're looking at probably a black screen or whatever bit of the credits were there when playback ended or you stopped it so it may seem different.
I'll look into it when I get home (2-3 hours) and post back and let you know. I hadn't thought about testing it using the built in player so I'll let you know.
Thx for the quick response.
- moby-uk - 2009-02-10
I've just updated my patch, so hopefully Jester will be along with a test-build, if not then I can make one available. In the meantime, the changes in this version ....
1) Reverted to locking the graphicscontext whilst the extenalplayer is playing
which prevents XBMC eating CPU-time whilst you're not using it.
There's a delay between starting the externalplayer and locking the context
to give the externalplayer time to open it's window above XBMC - this
defaults to 5000 (milliseconds) but can be set in advancedsettings with
Code:
<externalplayer>
<startuptime>nnnn</startuptime>
</externalplayer>increasing this value.
2) Added an option to use the externalplayer by default for DVDs, set in
advancedsettings
Code:
<video>
<defaultdvdplayer>externalplayer</defaultdvdplayer>
</video>3) The library views (video/music) are refreshed after the externalplayer quits
if you have "hide watched" enabled, this will ensure the just-watched item
is hidden. (This takes a little while; it's the same time as if you use the
built-in player but you might notice it more).
4) Items are no longer marked as watched if the externalplayer process fails to
start.
5) Added a mechanism to make some (regexp-driven) changes to the filename. This is
for those of you that wanted support for your externalplayers playing DVD folders, rars
and whatever else, however, you will have to do some legwork for this.
An example probably serves best:
Code:
<externalplayer>
...
<replacers action="prepend">
<replacer global="true">
<match>zip://.*</match>
<pat>%5c</pat>
<rep>\\</rep>
</replacer>
<replacer stop="true">
<match>zip://.*</match>
<pat>zip://(.)%3a(.*)%2ezip.*</pat>
<rep>\1:\2.\zip</rep>
</replacer>
</replacers>
</externalplayer>(by default) replacing the builtin values, which are defined only for WIN32
to turn an XBMC smb URI into a Win32 smb UNC. Each replacer can have a
"match" RE which controls whether the replacer is applied to the filename,
if it is then the "pat" RE is replaced with the "rep" string. (Specify
global="true" if you want to replace every occurrence of the "pat" RE)
If a replacer with stop="true" matches a filename then no more replacers are
run after than one (regardless of whether any pat/rep replacements are
actually made).
I know this looks complicated but there's too many variations on what the
path might look like in combination with what any given external player
would need it to look like. Your other option is of course to write a
wrapper for your external player and transform the path in any way you like
in there.
- taxigps - 2009-02-10
How to define a key that press it to play movie use externplayer?
- taxigps - 2009-02-10
moby-uk Wrote:Quote:
Originally Posted by jmarshall
@taxigps
Use the built in functions for that: g_charsetConverter.utf8ToW()
Quote:
Originally Posted by jmarshall
Yep - that'll be just fine.
@jmarshall
Is this OK to do in general or should it only be done for a UNICODE build (i.e. #ifdef UNICOCDE)?
I'm still not completely happy with just delaying locking the graphics context for 1 second to workaround the window-stacking issues. It isn't 100% reliable for me on slow hardware.
I think the method in general is check the system's charaters coding, convert to that code(not unicode) and then process CreateProcess function.
- moby-uk - 2009-02-10
taxigps Wrote:How to define a key that press it to play movie use externplayer?
Sorry, you can't.
- Jester - 2009-02-10
Build coming...
- Jester - 2009-02-10
Upped version with moby-uk's latest patch
XBMCSetup-Rev17640-jester-ext.exe
- ashlar - 2009-02-10
Jester Wrote:Upped version with moby-uk's latest patchAre we going to get this committed to SVN soon? Or is there stuff still happening with the Intel problems?
XBMCSetup-Rev17640-jester-ext.exe
- moby-uk - 2009-02-10
ashlar Wrote:Are we going to get this committed to SVN soon? Or is there stuff still happening with the Intel problems?
I've submitted a patch for the Intel-Vsync/TOPMOST/Can't-Alt-Tab issue that does what IMVHO is the best we're going to get. Waiting for someone to review/commit that.
- ashlar - 2009-02-10
moby-uk Wrote:I've submitted a patch for the Intel-Vsync/TOPMOST/Can't-Alt-Tab issue that does what IMVHO is the best we're going to get. Waiting for someone to review/commit that.Cool! Thanks for the update. Your work is much appreciated (at least by me
, even if I'm now using the internal player at 24Hz with good to excellent results).
- RandomXBMCUser - 2009-02-10
Even with the
<defaultdvdplayer>externalplayer</defaultdvdplayer>
line, xbmc still seems to play all dvds internally by default.
- moby-uk - 2009-02-10
RandomXBMCUser Wrote:Even with the
<defaultdvdplayer>externalplayer</defaultdvdplayer>
line, xbmc still seems to play all dvds internally by default.
My bad, looks like I lost that change in a merge
... I'll update the patch shortly.EDIT: updated the patch in trac (sorry)
- RandomXBMCUser - 2009-02-10
I'm just glad it's finally being implemented, thank you!
- THX-UltraII - 2009-02-11
I m very excited to see that the VIDEO_TS folder patch has made it s way to Jester s version! Thanks to Moby-UK and Jester!