Jump to content

DVBSource.ini empty & can't record


dvbrewer

Recommended Posts

After I used DVBViewer to shut down on Monday morning (via System>Power Off), I got prompted to start the setup wizard when running the exe, which I did. I thought everything was OK, but now I cannot record (it was working last night), also I notice DVBSource.ini is empty, support.zip attached.

support.zip

Link to comment

Check if your timers.xml is corrupted. Everything else looks fine.

What should I check for :)? I just have this text in it

 

<?xml version="1.0" encoding="iso-8859-1"?>

<settings>

<section name="VCR"/>

</settings>

Link to comment

Any help? Recordings still do not work, I press recording button with mouse, or use remote record button, nothing happens :huh:?

Edited by dvbrewer
Link to comment

OK, bizarre, I reinstalled, then recording worked, I shut down as usual with System>Power Off, now again I cannot record :blink:?

Edited by dvbrewer
Link to comment

Thanks, now it almost seems random when I can record, when I can't, I managed to record some HD, then couldn't record others, went back to them, then could record :| , support.zip attached.

support.zip

Link to comment
The system cannot find the path specified

Check your settings for the recording path and the settings for the recording name generation.

Link to comment

Check your settings for the recording path and the settings for the recording name generation.

Yes this is correct i.e. it matches the folder that is there, the recording name generation is %date_%time_%station_%name.

Link to comment

Just shorten the timer names. Or use other fields to generate the recording name. I doubt you need 250 char long file names. My guess: there is your problem.

 

how do you program the timers?

Link to comment

Just shorten the timer names. Or use other fields to generate the recording name. I doubt you need 250 char long file names. My guess: there is your problem.

Yes this does seem to fix this recording problem if I reset to my original naming system %year_%date_%time_%station_%event_%tshortthe , it doesn't explain though why I lost these settings in the first place and was prompted to run the DVBViewer Wizard after shutting down via System>Power Off.

Edited by dvbrewer
Link to comment

Yes this does seem to fix this recording problem if I reset to my original naming system %year_%date_%time_%station_%event_%tshortthe , it doesn't explain though why I lost these settings in the first place and was prompted to run the DVBViewer Wizard after shutting down via System>Power Off.

For me it's a common problem config files gets wiped out and replaced with default config. It started when going from F-secure internet security 2010 to 2011 and has continued to happening even with the 2012 version. RS config files are particularly affected and it usually happens in close proximity when opening the RS configurator (DVBVCtrl.exe). DVBViewer config files has only been wiped out once for me. Seems there's no way to prevent it and it has gotten me to take backup of the configs every time when there's a need to change a setting. Sometimes the settings stays sometimes they get wiped. It's a pain in the neck :(

 

I suppose what is happening is the application monitor in the firewall blocks vital exe's and RS and DVBV reacts with going back to defaults. IMHO way to flippant. The built in backup system in RS and DVBV for preventing this very thing does not work in this scenario :(

Link to comment

For me it's a common problem config files gets wiped out and replaced with default config. It started when going from F-secure internet security 2010 to 2011 and has continued to happening even with the 2012 version....

Thanks for this maj, I think you may be right and it is something to do with clash between AVs and DVBViewer, I should have said that I tried disabling Kaspersky and it allowed recording before I changed my recording naming system, also everytime I installed recent versions of DVBViewer Kaspersky stops the process as a detected P2P Worm so I have to disable it to install also. It seems that the fact DVBViewer is unsigned may be an issue to AVs- is there a reason why this is the case?

Edited by dvbrewer
Link to comment

It seems that the fact DVBViewer is unsigned may be an issue to AVs- is there a reason why this is the case?

Unfortunately in my quest getting to the bottom with this yields nothing in particular. F-secure does not acknowledge the problem and devs here think it is a firewall problem (probably rightly so). It is quite problematic when the firewall somehow ignores it's own settings (every exe realted to DVBV and RS is allowed) and still blocks it (in a sertain scenario which i haven't figured out yet). I suppose AVs heuristic functionality could play a role causing many brands getting more flaky during the recent years.

 

I would love to see the DVBV and RS backup system getting a bit smarter, telling us when config files (the important ones such as setup.xml and service.xml) is about to be defaulted and allowing us to stop it.

Link to comment

Well then it's too late.They default only if the file in question was corrupted. Actually there are several failsafes in place to prevent it.

But we can't prevent another software with ill-intend from sabotaging the writing of the files.

Link to comment

Hmm, smarter system would include the ability to determine which anti virus application is used. I somehow have the feeling that the av engines got worse and worse in the last years. For example, the smaller a binary is, the more suspicious it seems to be. If you create a simple application which uses WinInet at least avira raises an Virus alert. This behaviour is disabled if your application is > than 150kb. It seem to be one of the most important factor for a "smart" heuristic these days, that the evil binaries seem to small. Probably one of the reasons why neither Avira, nor Kaspersky are able to detect modern trojans. Anyway i suppose there are only a few choices:

1. (for developers): Increase the size of the binary - either via adding bitmap ressources

2. (for developers): don't use upx or aspack - compressed binaries are always suspicious

3. (for developers): Trusted certificates, they cost a hell, but they stop scanners from warning (probably because they are ---------------ing expensive)

4. for customers: use your brain and if you payed for the software you can add exceptions inside your av software

5. for customers: drop your av software manufacturer a mail and nag him with this issue (in many cases they get YOUR money, so YOU are in the right to make sure they DO THEIR job well)

6. use virustotal to check the binaries.

 

Holger

Link to comment

Well then it's too late.They default only if the file in question was corrupted. Actually there are several failsafes in place to prevent it.

But we can't prevent another software with ill-intend from sabotaging the writing of the files.

Why not get DVBViewer to auto backup vital settings in another folder, then if there is a problem revert to last working config?

 

4. for customers: use your brain and if you payed for the software you can add exceptions inside your av software

I already did that, added DVBViewer components as trusted and the installer, but still when I run the installer gets detected as a Worm P2P, and seemingly with my recording test it doesn't like DVBViewer making very long filenames.

Edited by dvbrewer
Link to comment

They default only if the file in question was corrupted.

Aha, i never understood this bit. Thanks for clarifying. It raises some question though and the one in mind is if RS/DVBV detects corruption why does it revert to defaults and not using the .bak (backup) to get the settings back? I suppose the backup of config files are done quite frequently and it can't be often a situation arises when there is no .bak file to fetch settings from in case of a corruption.

Link to comment

@LocalHolgi

I once wrote an instant virus. Actually I was testing some code to check if a IP is within a IP range and used some "lowlevel" Winsock functions.

 

As soon as I compiled the program the AV Software had a fit and moved it to quarantaine. I wasn't able to test it nothing and it was less than 10 code lines.

 

It boiled down to

const
 Mask1 = '255.255.255.192';
var
 vmask1 : Integer;
begin
VMask1 := htonl(inet_addr(pchar(Mask1)));

 

This caused the uproar. I made a console app with only this piece of code and bamm virus. I think this says a lot about the "hyper intelligent blah blah" detection routines ;)

 

Even today the AV (I changed to another program after the above incident) still complains about one of my test programms (it reads the MAC of a network device). Everytime I back it up it gets deleted.

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Unfortunately, your content contains terms that we do not allow. Please edit your content to remove the highlighted words below.
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...