XBMC Frodo conflicting with DVBViewer client

[DisTreSs]

support.zipHi,

 

I've had a setup running perfectly where I started up my DVBViewer client (served by the Recording service) from within my XBMC Eden build through advanced launcher without issues.

This worked perfectly until I decided to upgrade to XBMC Frodo...

 

All of a sudden DVBViewer will only display either a black screen (no image) or an immensely stuttering stream (picture changes once every 10 seconds) when XBMC is open.

The moment I close XBMC though, DVBViewer resumes playback as if nothing ever happened. Since XBMC, in the way I was using it up until now, needs to be open at all times, I now have a serious problem.

 

Is this a problem where both software are competing for the same display drivers or something?? I don't really know where to begin troubleshooting to be honest. Any help would really be appreciated as I now have to explain to the people at home here how to open DVBViewer manually

 

I've included the support.zip for more details, but if you need more info, I would be glad to respond of course.

 

PS: I've also tried LiveTV from within XBMC and as far as I'm concerned it sucks... I can see a lot of promise there, but as long as not all kinks have been ironed out, I would much prefer to continue using DVBViewer as a client!

Edited November 26, 2012 by DisTreSs

[Lars_MQ]

Please report all problems regarding other software to the respective authors.

[Griga]

Check the XBMC CPU load and process priority in the Windows task manager. Give DVBViewer a higher priority (DVBViewer Options -> Extended -> Priority).

[DisTreSs]

Please report all problems regarding other software to the respective authors.

 

Hi Lars, I understand that there is a good chance that this is down to a fault with XBMC and appreciate that I should find support there, but their forum is so vast and nothing is specifically in place that is dedicated to DVBViewer, that I thought I would be better off asking here. Sorry if this was not appropriate...

I was just hoping that this was something that other DVBViewer users might have experienced when upgrading XBMC and that a quick fix would already exist.

 

Check the XBMC CPU load and process priority in the Windows task manager. Give DVBViewer a higher priority (DVBViewer Options -> Extended -> Priority).

Hi Griga, I always set my DVBViewer priority to the highest setting. It was already set that way when I experienced the issue. Maybe I can see if XBMC's priority can be turned down, but I don't think so...

Thanks for your reply though!

[Griga]

Maybe I can see if XBMC's priority can be turned down, but I don't think so...

Of course you can. Find the process in the Windows task manager's process list -> right-click it -> set the priority.

 

However, chances are that XBMC occupies other resources heavily, as if being alone on the PC Maybe network resources, since you are using the Unicast Device in DVBViewer.

[DisTreSs]

Of course you can. Find the process in the Windows task manager's process list -> right-click it -> set the priority.

 

However, chances are that XBMC occupies other resources heavily, as if being alone on the PC Maybe network resources, since you are using the Unicast Device in DVBViewer.

 

How could I overlook that

Guess I wasn't thinking outside the XBMC-box

 

Anyway, lowering priority of XBMC didn't change it...

 

Resource usage (CPU/mem) of XBMC are on a par with DVBViewer, there is nothing excessive in either case.

Network resource shouldn't come into play I guess since everything is on the same pc (Rec service, DVBViewer, XBMC)?

 

Besides, things worked great with Eden on the same system, so it's probably something that got changed in Frodo. If I have DVBViewer open, it stops streaming from the moment I click on XBMC...

Maybe I should try one of the nightly builds?

I think the least I can say is that it's clear that this is not a common problem apparently, so I'll try my luck at the XBMC forum.

Thanks for trying to help Griga!

[DisTreSs]

Just in case someone else runs into this problem: mine was solved by using a nightly build of XBMC