got the beta version up and running - client and server both working straight out the box. Many thanks - all the hard work paid off!
Because it says it won't work on the client and the server at the same time, the first thing I did was to try and run it on both to see what happened (Im the kind of guy that just can't help pressing the big red button marked 'don't push'). Of course it eventually crashed both machines - but in the process I came up with a possible work around (until a full multi instance version is released
) - would it be feasible to instigate some sort of clone mode on the client whereby the radio buttons are disabled, but it can play back the mp3 being generated on the server so at least you can have radio in both rooms, even if it's the same channel and controlled from one room only? That's basically what I get if I hit play on both machines and leave it alone - it obviously doesn't like being controlled from two locations simultaneously or told to play two different stations at once (that's what crashed them).
EDIT: so now i'm trying to use the plugin 'properly' and just to let you know it all works wonderfully on the client OR the server. My only request would be some kind of logic to prevent button presses on the other machine (either way round) being recognized to avoid any lock-ups and keep the WAF up.
ps The wiki states that the client only works in file sharing mode - mine's set to streaming in the main gbpvr config and on first inspection seems to work fine. Is this just good luck, or do you mean that just the dvbt plugin is working in file sharing mode?
fuzzweed Wrote:got the beta version up and running - client and server both working straight out the box. Many thanks - all the hard work paid off!
Great stuff - I was waiting for some client-mode feedback, thanks.
Quote:Because it says it won't work on the client and the server at the same time, the first thing I did was to try and run it on both to see what happened (Im the kind of guy that just can't help pressing the big red button marked 'don't push').
One of my favourite mottos is "Hey - let's hit it and see what happens!"
Quote:would it be feasible to instigate some sort of clone mode on the client whereby the radio buttons are disabled, but it can play back the mp3 being generated on the server so at least you can have radio in both rooms, even if it's the same channel and controlled from one room only?
OK - I like the suggestion but it'll need some work. If you start the radio on the server then 15 minutes later (for example) start it on the client, it'll start playing the buffer mp3 from the beginning, i.e., 15 minutes behind actual broadcast. Useful if the person at the client missed the start of the programme but not what some people might want. I have an idea how to get this to work but it'll take time. The whole multi-instance thing is still being formulated.
Quote:ps The wiki states that the client only works in file sharing mode - mine's set to streaming in the main gbpvr config and on first inspection seems to work fine. Is this just good luck, or do you mean that just the dvbt plugin is working in file sharing mode?
The difference between streaming and file sharing client mode in GB-PVR is that the client doesn't need a fileshare for the recordings or LIveTV folders to playback mpeg files in streaming mode - they're streamed via the server's GBPVRRecording service. The current version of GB-PVR only supports this for mpeg files although sub has said he'll try and add mp3 support. If it's working for you on your client, there must be a valid fileshare for the server's Recordings folder embedded in the client's config.xml - check your DvbtrClient.log and you should see it is playing something like \\myserver\Recordings\gbnetradio-X.mp3.
Cheers,
Brian
fuzzweed Wrote:ps The wiki states that the client only works in file sharing mode - mine's set to streaming in the main gbpvr config and on first inspection seems to work fine. Is this just good luck, or do you mean that just the dvbt plugin is working in file sharing mode?
Brian - in light of this I retried DeeVeeBeeTee on the client running in streaming mode and it seems to work fine now...
Quote:25/06/2008 22:55:04.997 Invoking PlayAudioFile() for \\Acer02\PVR\Recordings\gbnetradio-2.mp3
25/06/2008 22:55:06.654 PlayAudioFile() invoked.
I'm still running an in between version (DVB-T Radio.dll shows version 1.2.3083.36051 from 12/06/2008).
I'll install the latest beta from the wiki and let you know...
Alex
Brian
I just installed the latest beta from the wiki on the server and on the client and it still works fine with client set to streaming...
Alex
ACTCMS Wrote:Brian - in light of this I retried DeeVeeBeeTee on the client running in streaming mode and it seems to work fine now
LOL - it's a 'feature'.
In this case, I'll define 'feature' to mean
a bug which doesn't actually break anything but makes the software behave in a way that neither the user or developer expected.
I just checked my code and I don't actually check to see if client-mode is set for streaming or file-sharing. That means that if you've ever had you client set to file-sharing mode and the paths to the shares on the server are still valid, dvbt radio will still work (using the fileshares) if you switch your client to streaming mode. You can have your cake and eat it.
Ahem...all planned of course.
Cheers,
Brian
bgowland Wrote:LOL - it's a 'feature'.
Ahem...all planned of course.
Cheers,
Brian
Phew - I was beginning to think that I had screwed up earlier in my normally rigorous testing...
It makes absolute sense though, you can even see the shares in config (although they are dimmed out)... I should have thought to retry streaming before.
Still, it's a great feeling when you discover this sort of feature in your code - it's a sign of well structured code...
Alex
Note to self: pay a bit more attention when your are testing...
ACTCMS Wrote:Still, it's a great feeling when you discover this sort of feature in your code - it's a sign of well structured code...
I work on the principle that 'bugs' write themselves or are the product of evil code goblins that visit when I'm not looking - 'features', however, are divine inspiration.
The reality is that both are usually a result of one too many beers and not enough sleep.
@fuzzweed - thanks for pointing this out. Looks like I need to edit the wiki to clarify things.
Cheers,
Brian
bgowland Wrote:'features', however, are divine inspiration.
For me 'features' are always a product of the 'when I wrote this code, only God and I knew how it worked...' syndrome.
Beer definitely helps though...
Quote:one too many beers and not enough sleep
BTW I understand 'not enough sleep', but what's this 'one too many beers' thing?
Alex