Jump to content

Recommended Posts

Posted (edited)
:lol: Nope we can't - you're very trying !!

:lol:

 

 

Have you pointed this out to Nic W the programs author ? He might be as keen as LUK! to fix his program.... :)

I most certainly have ;) This is a more minor point since it's unlikely users will uninstall it very often, but if I use software a lot then I like to report any bugs/suggestions so I can get the software working to my satisfaction.

 

I actually do this on purpose sometimes just to see how things are working with the s/ware. I start a burn from a network drive and then request the same image or another large file from the same drive using a few other PCs (Basically overloading the drive with requests).. It's guaranteed to empty the buffer and bring the burn to a complete halt. In this example, Burnproof does what it's supposed to do when the buffer empties. Incredibly, it worked fine last week, last month, last year, the year before that and the year before that and...........

Do you not find that the burn continues intermittently (ie. the LED on the drives flickers on/off) so, while it will finish the burn successfully, it will take a lot of burn cycles ?

 

The improvements I suggested were aimed at reducing the number of burn cycles (ie. zeroless links required) during times when the source disk is under high load, in the hope that the burn quality would be increased.

 

 

BTW LUK, would I be right in thinking that setting these new values to 0 will effectively disable this new feature, so the original behaviour can be obtained again ?

 

While I will keep it enabled most of the time, I will try to do some test burns during high disk load to see if the quality is indeed affected by increased link stages.

Edited by Defenestration
Posted

Guess I'd better put another beta out then so you can all get started :P

Since I'm the only one who seems to suffer from these problems, maybe I can get a copy to test this new buffer underrun feature ? :whistling:

 

 

 

I'm with you on this, i have the same with my laptop. Personally i queue all the files to be burnt and when ready i shut down all no essential apps' and burn said files. Been doing this since i had trouble many months ago, we never really got to the root of the problem at the time but doing things like this i now burn/verify in 10/12 minutes without any under run. :)

Posted

D ,you seem really knowledgable in the programming dept., have you ever considered writing your own burning program I'm sure it would be incredible with all the bells and whistles it would be massive ,cant have enough free programs out there :thumbup:

Posted (edited)
D ,you seem really knowledgable in the programming dept., have you ever considered writing your own burning program I'm sure it would be incredible with all the bells and whistles it would be massive ,cant have enough free programs out there :thumbup:

I can write a program that prints "Hello World" :lol:

 

I think it would be pointless to write another burning app when LUK has already done such a superb job with ImgBurn. I would consider helping LUK out with the programming side of things if he so wished, although I couldn't guarantee how much time I could spend working on it.

 

While ImgBurn is already pretty light on RAM resources, I think it could be improved by switching from Borland windows framework to Win32 or WTL (probably the better option, but I think it only works with VC++ at the moment), but doing this is certainly not a necessity, more a nicety. Other than that, the only new features I would like to see in ImgBurn would be

 

1) Burn files/folders (- being implemented in version 2)

2) Multi-session support for RW discs

3) Copy unprotected CD/DVD, with ability to specify number of copies (ie. create ISO image and then burn it X number of times). It shouldn't just use the files/folders, instead copying sectors so all information is retained (eg. boot information with bootable discs)

4) Support for burning Audio CD's

5) Blue Ray/HD-DVD support (don't have a drive now, but will no doubt have one in the future)

 

and maybe a couple of other things I can't remember at the moment. That would probably suffice for me and allow me to get rid of Nero.

 

I'd be interested to hear from LUK what his plans are for ImgBurn and how far he intends to take it.

Edited by Defenestration
Posted

I'm sure he'll run it by you he's always open to suggestions he's really great like that, so many suggestions from members have made it into the new releases its amazing and I believe he's going to include some new stuff thats going to blow everybody away but I'm probably out of line for even mentioning it so I wont really get into it ,the program has come such a long way since its inception I stand in awe :worthy:

Posted

I actually do this on purpose sometimes just to see how things are working with the s/ware. I start a burn from a network drive and then request the same image or another large file from the same drive using a few other PCs (Basically overloading the drive with requests).. It's guaranteed to empty the buffer and bring the burn to a complete halt. In this example, Burnproof does what it's supposed to do when the buffer empties. Incredibly, it worked fine last week, last month, last year, the year before that and the year before that and...........

Do you not find that the burn continues intermittently (ie. the LED on the drives flickers on/off) so, while it will finish the burn successfully, it will take a lot of burn cycles ?

Not only do I find the burn continues intermittently, I expect it, regardless of the strain put on the source drive. Unless you have some way of prioritising a particular stream of data through your gateway/router/switch using IP addresses and a queue system of some sort, your hardware, by default, will try to satisfy all requests for data with equality - meaning that data will be handled via a cyclical or rotary type of arrangement. eg..

 

Point A is the source drive. If requests come from point B, C, D and E, all requests will be treated as equal and data will be streamed to these clients accordingly. Data might be sent to point B then point C then point D then point E then back to point B and so on. If no data (or all data) arrives at one of these points, I'd be asking myself where the problem is.

Posted
and maybe a couple of other things I can't remember at the moment. That would probably suffice for me and allow me to get rid of Nero.

Let's just put things into perspective here. Nero is a commercial product. Commercial software is expected to have bells and whistles if a company expects to make any money. ImgBurn is the brainchild and hobby of a single (albeit talented) programmer wishing to share his gift with those of us lacking any programming skills whatsoever. This forum (again, because the author wishes to share) is available to one and all for the purpose of supporting those who use his software. It's not a forum dedicated to users for the sole purpose of telling the author how his program should function, the features that should be included or what compiler should be used.

 

Many of us "users" have years invested in this (and the old) forum. We take no small amount of pride in being able to share what we have learned with others. We "old timers" take a dim view of new users wanting a grocery list of changes made to what is already a fantastic program. (Version 2 will be even better with 15 betas tested so far).

 

FWIW, the current beta happily creates a 400gig ISO and also supports on-the-fly burning to +/- DL DVD. I humbly suggest that next time you think of something you don't like about the way Lightning_UK! codes, what compiler he uses, what the software should and should not do, contemplate it for a while before posting. Your constant demand for attention is really starting to fuck me off.

Posted (edited)

Shamus, I agree with Kev, well said!

 

I have felt for some time that he was being very overbearing with his posting and constant complaining of what LUK is/was doing. Even thought I have been around since the old site I didn't think it was my place to be the first to post anything.

Edited by Movie Junkie
Posted
Not only do I find the burn continues intermittently, I expect it, regardless of the strain put on the source drive. Unless you have some way of prioritising a particular stream of data through your gateway/router/switch using IP addresses and a queue system of some sort, your hardware, by default, will try to satisfy all requests for data with equality - meaning that data will be handled via a cyclical or rotary type of arrangement. eg..

 

Point A is the source drive. If requests come from point B, C, D and E, all requests will be treated as equal and data will be streamed to these clients accordingly. Data might be sent to point B then point C then point D then point E then back to point B and so on. If no data (or all data) arrives at one of these points, I'd be asking myself where the problem is.

Your point being ?

 

I know that's how a drive works. My original post (if you actually bothered to read it) was about trying to improve the quality of a burn during times of high disk activity. I can't see the problem of building some protection against intermittent burning into ImgBurn so that it temporarily stops requesting data until the free-for-all with the hard-disk is over.

Posted
Let's just put things into perspective here. Nero is a commercial product. Commercial software is expected to have bells and whistles if a company expects to make any money. ImgBurn is the brainchild and hobby of a single (albeit talented) programmer wishing to share his gift with those of us lacking any programming skills whatsoever. This forum (again, because the author wishes to share) is available to one and all for the purpose of supporting those who use his software. It's not a forum dedicated to users for the sole purpose of telling the author how his program should function, the features that should be included or what compiler should be used.

I understand it's a hobby and appreciate the amount of work LUK puts in to developing such a great application, as I have said before. It seems odd that an "old timer" does not even know what this forum is for - you say it is only for support of those who use ImgBurn, but if that's the case then why are there sub-forums for posting/discussing bugs and suggestions ?

 

Many of us "users" have years invested in this (and the old) forum. We take no small amount of pride in being able to share what we have learned with others. We "old timers" take a dim view of new users wanting a grocery list of changes made to what is already a fantastic program. (Version 2 will be even better with 15 betas tested so far).

You say above that ImgBurn is the brainchild and hobby of LUK, but yet you come across as considering ImgBurn to be your app which no-one else is allowed to comment on. Without change, ImgBurn would not be what it is today!

 

FWIW, the current beta happily creates a 400gig ISO and also supports on-the-fly burning to +/- DL DVD. I humbly suggest that next time you think of something you don't like about the way Lightning_UK! codes, what compiler he uses, what the software should and should not do, contemplate it for a while before posting. Your constant demand for attention is really starting to fuck me off.

Where did I say I didn't like the way LUK codes ? I didn't!

 

Where did I say I don't like the compiler he uses ? I didn't! I merely suggested the RAM usage may be reduced by using the Win32 API (which can be done with Borland) or WTL (which I don't believe can be done with Borland).

 

You'd be great to have in a game of Chinese whisper's. Read/Hear one thing, and it suddenly has a completely different meaning.

 

I have posted my suggestions (and possible ways to implement it on occassions) because, even though you don't want to hear them, the author of ImgBurn, LUK, apparently does. I can honestly say I'm glad you are not developing ImgBurn! :lol:

 

Maybe you're feeling insecure from someone else coming on these forums and "taking your thunder", and if that's the way you perceive me then that's your problem.

 

Even thought I have been around since the old site I didn't think it was my place to be the first to post anything.

Jump on the bandwagon why don't you :)

 

If you never ask for something, you may never get it! Forums are places for open discussion (not that you'd know that if you listened to Shamus).

Posted

You come across, at least to me, as an arrogant, cocky person. I believe you have an unhealthy need to control evereything you're involved with including this forum. I really don't want to have anything to do with you. I'll just leave it a that.

Posted
You come across, at least to me, as an arrogant, cocky person. I believe you have an unhealthy need to control evereything you're involved with including this forum. I really don't want to have anything to do with you. I'll just leave it a that.

Sorry I've given you that impression, and just to live up to your impression of me I need to say "Your loss" :P

Posted
Sorry I've given you that impression, and just to live up to your impression of me I need to say "Your loss" :P
If by "Your loss" you mean me personally you are wrong. I don't come here to take things from people. I come here to try and help. If something is offered by others (like LUK) it doesn't come with strings attached. If by "Your loss" you don't mean just me but everybody here, then that just shows me how petty you are. If you actually have something that people here could use and you deny them the item because you have a problem with what I perceive you to be, you are VERY immature. Sort of like the child who tells others that unless they play ball his way he is going to take he ball and leave.
Posted (edited)

Shame about this thread. Some good things in here from a knowledgeable poster, combined with poor "delivery" from same.

 

@D - I have found LUK to take all suggestions seriously and consider them. No need to ever be overbearing or demanding - the guy only needs to be asked once. I've always found him to respond thoughtfully to any request, even if he doesn't agree to implement it.

 

Regards

Edited by blutach
Posted

Not only do I find the burn continues intermittently, I expect it, regardless of the strain put on the source drive. Unless you have some way of prioritising a particular stream of data through your gateway/router/switch using IP addresses and a queue system of some sort, your hardware, by default, will try to satisfy all requests for data with equality -

Your point being ?

 

I know that's how a drive works. My original post (if you actually bothered to read it) was about trying to improve the quality of a burn during times of high disk activity.

The quality is dependant on the source, the destination and the media, not the speed at which it is written. If Burnproof is enabled (you have heard of burnproof, haven?t you), high disk activity hasn?t got a fucking thing to do with quality.

 

(Anyone got some crayons so I can draw this clown a picture?)

Posted

As this thread is nothing more than a slanging match now, I'm gonna close it.

 

It was a good suggestion even if it wasn't suggested in the best possible manner.

Guest
This topic is now closed to further replies.
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.