de-luxe / burstcoin-jminer Goto Github PK

user should be notified if plot-files are incomplete ... if size from filename does not match real size.

Jminer stops mining randomly, usually after a couple days of running. Has happened twice in the last week. Sadly there is no way to automatically detect this failure so I have to check it every day to ensure it has not stopped.

When it stops it simply does not print any more text. I can get it unstuck by pressing ctrl-c. When I do this I get the printouts shown in the attached image.

Any idea what might cause this or what can be done to fix this? Let me know if there is anything I can provide to help determine the cause of the issue.

I am launching with this in the run.bat:

java -jar -d64 -XX:+UseG1GC -Xms8G -Xmx12G burstcoin-jminer-0.4.10-SNAPSHOT.ja

If this issue cannot be fixed, could a timestamp be printed upon completion of each round so that it is easy to see if it is still working?

Relevant System Information:

JVM - build 1.8.0_131-b11
Windows 10 Pro - Version 1703
Nvida GeForce Driver Version 384.76
GTX 770
8 8TB plots
16GB Ram
8 core i7-7700K

Copy of my config file:
copy_of_jminer_conf_file.txt

Image of the resulting text after I press ctrl-c (much longer than pictured, next time I will copy the raw text, no useful information though so no great loss). Note that before I pressed ctrl-c it only showed the successfully printed block so there was no way to see that it was stuck without waiting for 5-10 minutes to see if it moved to the next block.

Hi Guys,

I hope you could help to solve the problem of jminer not working on Raid 0 configured drive. It is 2 drive setup (6TB) 3TB plotted. Do you have any suggestion how jminer.properties should be configured to mine Burstcoin
Would be very grateful for advice.

Cheers

currently logLevel is always INFO, but there are some informations in DEBUG that may be useful/interesting for users, too. So it should be adjustable in jminer.properties.
use TRACE for real debugging 'internal' stuff.

1. after round is finished, the workers in readerPool still had allocated memory depending on the plot-files they mined ... the drive<->worker relation is not deterministic, that could lead to a growing memory usage with every round ... (to a limited point, all workers had the worst case plot once)
   however this should be fixed by cleaning up readerPool on finish round.
2. we should trigger garbage collection more often ... to prevent growing memory usage while round is running.
3. user should get a property to adjust memory usage, even if round would take longer ... so there will be a readerThreads property
4. memory usage is higher on fast block interrupt, that should be optimized

show average and effective read info.
average - since round start
effective - since last info

Has anybody has this message, the drive starts to go into repetitive periodical noise, and this error appears in the miner as the block continues.

Getting few of these errors in version 0.4.11 while mining on pool http://pool.burstcoin.ro/, any idea how critical these are?

2017-10-16 19:47:01.717 INFO 1382 --- [ roundPool-1] burstcoin.jminer.JMinerCommandLine : dl '795870' send (pool) [nonce '55004397']

2017-10-16 19:47:01.942 WARN 1382 --- [askExecutor-275] b.j.c.n.task.NetworkSubmitPoolNonceTask : Error: On submit nonce to pool, could not parse response: '{ "result" : "success", "deadline" : 60218566784215, "deadlineText" : "1,936,039y 3m 22d 14:16:55" }'

2017-10-16 19:47:01.944 INFO 1382 --- [askExecutor-275] burstcoin.jminer.JMinerCommandLine : dl '795870' NOT confirmed! [ 9d 5h 4m 30s ]

add some more support for user to easy setup openCL

It may happen that wallet/pool was on fork and corrects while mining, this case has to be detected and round has to restart.

I just tried on my MacMini:

$ ./run.bat

I got:

Exception in thread "main" java.lang.UnsupportedClassVersionError: burstcoin/jminer/JMinerApplication : Unsupported major.minor version 52.0
	at java.lang.ClassLoader.defineClass1(Native Method)
	at java.lang.ClassLoader.defineClass(ClassLoader.java:791)
	at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)
	at java.net.URLClassLoader.defineClass(URLClassLoader.java:449)
	at java.net.URLClassLoader.access$100(URLClassLoader.java:71)
	at java.net.URLClassLoader$1.run(URLClassLoader.java:361)
	at java.net.URLClassLoader$1.run(URLClassLoader.java:355)
	at java.security.AccessController.doPrivileged(Native Method)
	at java.net.URLClassLoader.findClass(URLClassLoader.java:354)
	at java.lang.ClassLoader.loadClass(ClassLoader.java:423)
	at org.springframework.boot.loader.LaunchedURLClassLoader.loadClass(LaunchedURLClassLoader.java:94)
	at java.lang.ClassLoader.loadClass(ClassLoader.java:356)
	at org.springframework.boot.loader.MainMethodRunner.run(MainMethodRunner.java:46)
	at org.springframework.boot.loader.Launcher.launch(Launcher.java:87)
	at org.springframework.boot.loader.Launcher.launch(Launcher.java:50)
	at org.springframework.boot.loader.JarLauncher.main(JarLauncher.java:51)

Forwarding nonces to a proxy-miner is something I always wished for in JMiner. On the other hand, what I found was that it's pretty easy to forward nonces from JMiner to CreepMiner if you do the following.

• Set up CreepMiner in "proxy"/forward mode
• Set JMiners config to point to the URI of CreepMiner: poolServer=http://CreepMiner.URI:8080
• Recompile JMiner to also submit the following HTTP-POST requests to the "proxy": X-Deadline,X-Plotfile,X-PlotsHash.

X-Deadline contains the DL in seconds
X-Plotfile contains the plot-file in which the DL has been found.
X-PlotsHash can be any arbitrary hash that is unique for this mining device, which acts as identifyer for summing up all X-Capacity data from all miners.

I quickly have implemented a "hacky"/sloppy way in a fork of JMiner and CreepMiner accepts the JMiner inputs now without any issues: https://github.com/systemofapwne/burstcoin-jminer

To use all HTTP-POST variables as intended one needs to spend a little more work

• The X-PlotsHash value should be properly calculated to make it unique. CreepMiner uses SHA1 on a list of the paths to all (active and working) plot-files. My "hack" simply uses the capacity of the miner.
• X-Plotfile should be set accordingly to the plot-file, where the nonce has been found. Right now I use a dummy-string.

two different versions of jminer are not needed as the openCL 2.0 version just uses openCl 1.2 by code and has no performance benefit. so switch back to only jocl-0.1.9. makes it less confusing for users ... thx fuse!

sometimes it happens, that finish log is triggered before the start log ... some timing issue, harden triggerFinishRound.

https://en.wikipedia.org/wiki/Byte

User should be able to decide if he wants info in TB or TiB etc.
However currently jminer calculates TiB and says TB.

on solo there is a CorruptPlot handling, this is needed for pool, too.

e.g. ninja pool:
b.j.c.n.task.NetworkSubmitPoolNonceTask : Error: Submit nonce to pool not successful: {"errorCode":1007,"errorDescription":"The deadline for your nonce is REALLY BAD: 123629 years, 6 months, 23 days, 21 hours, 46 mins, 52 secs - wrong block? are your plot files corrupted?"}

has no effect on mining

useful for looking up history etc.

tiny error in the 0.4.7 released! you forgot to update "run.sh" and "run.bat" to 0.4.7 !-)
Thanks for all the hard work!

Should be replaced with e.g. BigInteger if possible.

Please check the submitNonce procedure for the pool.
There is no deadline or x-deadline that should get the current miner nonce calculated deadline.
The x-deadline is used by CreepSky to pass the actual deadline in sec or dedline is used by Blago to pass the deadline based on baseTarget.

on NetworkSubmitPoolNonceTask.java is only one change:

  ContentResponse response = httpClient.POST(poolServer + "/burst")
    .param("requestType", "submitNonce")
    .param("accountId", numericAccountId)
    .param("nonce", nonce.toString())

   .param("x-deadline", calculatedDeadline.toString())

    .header("X-Miner", HEADER_MINER_NAME)
    .header("X-Capacity", String.valueOf(gb))
    .timeout(connectionTimeout, TimeUnit.MILLISECONDS)
    .send();

Please add it to your miner.

add new property, that allows to log the performance of plot-drives, to enable finding slow drives to e.g. optimize setup

currently all logs are written to logfile, should be a optional feature

It may happen, that due to a corrupted plot or read error a miner calculated deadline does not get confirmed by a pool (or wallet in case of solo).

Miner has to ensure, that if that happens, the next higher best deadline does not get skipped, but queued and committed, in case that the above happens.

Hi, I have been trying to slim console output as the miner works without issues. When I tried to set readProgressPerRound=0 to switch it off, I got division by zero error. It would be nice to have a little more control over the output.

I apologize upfront, but I'd like to use this opportunity (as burst-team.us forum is down) to ask a PoC related question: I went through the jMiner source code and I think I got quite clear picture how it works (also thank to the fact it is so much cleaner code, then the one of Burst wallet full node). I understand it polls /getMiningInfo service of a pool or local wallet to get the information whether there is newer block and if yes it tries its best to find and post the best deadline from each plot to /submitNonce.

However what I can not get up to is how the new block is actually generated in the network. Just before the mining round starts, pool UI says This block was generated by: BURST-xxx what seems like it was already processed.

1. What is then the trigger for new block generation for which the mining subsequently occurs?
2. What does it mean 'generated' if the best deadline race only starts afterwards?
3. If it is 'generated' by one node and subsequently propagated to peers, how it is achieved, that the nodes agree what was the best deadline? (e.g. it happened to me that my miner found really good 2 seconds deadline that was submitted to the pool. However block was forged by another address with much longer deadline from another pool. Occurred more then once to me.) Is there a sort of time limit up to which the nodes accept new deadlines? I could not figure out the concept from wallet code.

Sorry for not so jMiner related questions, but perhaps it would help the others to grasp the concept as well. All 'intro' descriptions are rather high level and do not scratch the surface. You apparently went through all of that as the author of well written pool and miner software.

Thanks
Michal

• bug: reset elapsedTime on not finished round
• add new event to log info about progress on not finished round

'Winner feature disabled, property 'walletServer' undefined!' always shwn on poolMining, even if specified.

./run.sh
22:07:52.380 [main] INFO burstcoin.jminer.JMinerApplication - Starting the engines ... please wait!
2018-01-17 22:07:53.140 INFO 26252 --- [ main] b.jminer.core.checker.util.OCLChecker : -------------------------------------------------------
2018-01-17 22:07:53.142 INFO 26252 --- [ main] b.jminer.core.checker.util.OCLChecker : List of system openCL platforms and devices (* = used for mining)
2018-01-17 22:07:53.142 INFO 26252 --- [ main] b.jminer.core.checker.util.OCLChecker :
2018-01-17 22:07:53.143 WARN 26252 --- [ main] s.c.a.AnnotationConfigApplicationContext : Exception encountered during context initialization - cancelling refresh attempt: org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'OCLChecker': Invocation of init method failed; nested exception is org.jocl.CLException: CL_PLATFORM_NOT_FOUND_KHR
2018-01-17 22:07:53.153 ERROR 26252 --- [ main] o.s.boot.SpringApplication : Application startup failed

org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'OCLChecker': Invocation of init method failed; nested exception is org.jocl.CLException: CL_PLATFORM_NOT_FOUND_KHR
at org.springframework.beans.factory.annotation.InitDestroyAnnotationBeanPostProcessor.postProcessBeforeInitialization(InitDestroyAnnotationBeanPostProcessor.java:137) ~[spring-beans-4.3.9.RELEASE.jar!/:4.3.9.RELEASE]
at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.applyBeanPostProcessorsBeforeInitialization(AbstractAutowireCapableBeanFactory.java:409) ~[spring-beans-4.3.9.RELEASE.jar!/:4.3.9.RELEASE]
at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.initializeBean(AbstractAutowireCapableBeanFactory.java:1620) ~[spring-beans-4.3.9.RELEASE.jar!/:4.3.9.RELEASE]
at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:555) ~[spring-beans-4.3.9.RELEASE.jar!/:4.3.9.RELEASE]
at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:483) ~[spring-beans-4.3.9.RELEASE.jar!/:4.3.9.RELEASE]
at org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject(AbstractBeanFactory.java:306) ~[spring-beans-4.3.9.RELEASE.jar!/:4.3.9.RELEASE]
at org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:230) ~[spring-beans-4.3.9.RELEASE.jar!/:4.3.9.RELEASE]
at org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:302) ~[spring-beans-4.3.9.RELEASE.jar!/:4.3.9.RELEASE]
at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:197) ~[spring-beans-4.3.9.RELEASE.jar!/:4.3.9.RELEASE]
at org.springframework.beans.factory.support.DefaultListableBeanFactory.preInstantiateSingletons(DefaultListableBeanFactory.java:761) ~[spring-beans-4.3.9.RELEASE.jar!/:4.3.9.RELEASE]
at org.springframework.context.support.AbstractApplicationContext.finishBeanFactoryInitialization(AbstractApplicationContext.java:867) ~[spring-context-4.3.9.RELEASE.jar!/:4.3.9.RELEASE]
at org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:543) ~[spring-context-4.3.9.RELEASE.jar!/:4.3.9.RELEASE]
at org.springframework.boot.SpringApplication.refresh(SpringApplication.java:693) ~[spring-boot-1.5.4.RELEASE.jar!/:1.5.4.RELEASE]
at org.springframework.boot.SpringApplication.refreshContext(SpringApplication.java:360) ~[spring-boot-1.5.4.RELEASE.jar!/:1.5.4.RELEASE]
at org.springframework.boot.SpringApplication.run(SpringApplication.java:303) ~[spring-boot-1.5.4.RELEASE.jar!/:1.5.4.RELEASE]
at burstcoin.jminer.JMinerApplication.main(JMinerApplication.java:68) [classes!/:0.4.11-SNAPSHOT]
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[na:1.8.0_151]
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) ~[na:1.8.0_151]
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[na:1.8.0_151]
at java.lang.reflect.Method.invoke(Method.java:498) ~[na:1.8.0_151]
at org.springframework.boot.loader.MainMethodRunner.run(MainMethodRunner.java:48) [burstcoin-jminer-0.4.11-SNAPSHOT.jar:0.4.11-SNAPSHOT]
at org.springframework.boot.loader.Launcher.launch(Launcher.java:87) [burstcoin-jminer-0.4.11-SNAPSHOT.jar:0.4.11-SNAPSHOT]
at org.springframework.boot.loader.Launcher.launch(Launcher.java:50) [burstcoin-jminer-0.4.11-SNAPSHOT.jar:0.4.11-SNAPSHOT]
at org.springframework.boot.loader.JarLauncher.main(JarLauncher.java:51) [burstcoin-jminer-0.4.11-SNAPSHOT.jar:0.4.11-SNAPSHOT]
Caused by: org.jocl.CLException: CL_PLATFORM_NOT_FOUND_KHR
at org.jocl.CL.checkResult(CL.java:808) ~[jocl-2.0.0.jar!/:na]
at org.jocl.CL.clGetPlatformIDs(CL.java:2173) ~[jocl-2.0.0.jar!/:na]
at burstcoin.jminer.core.checker.util.OCLChecker.initChecker(OCLChecker.java:88) ~[classes!/:0.4.11-SNAPSHOT]
at burstcoin.jminer.core.checker.util.OCLChecker.postConstruct(OCLChecker.java:78) ~[classes!/:0.4.11-SNAPSHOT]
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[na:1.8.0_151]
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) ~[na:1.8.0_151]
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[na:1.8.0_151]
at java.lang.reflect.Method.invoke(Method.java:498) ~[na:1.8.0_151]
at org.springframework.beans.factory.annotation.InitDestroyAnnotationBeanPostProcessor$LifecycleElement.invoke(InitDestroyAnnotationBeanPostProcessor.java:366) ~[spring-beans-4.3.9.RELEASE.jar!/:4.3.9.RELEASE]
at org.springframework.beans.factory.annotation.InitDestroyAnnotationBeanPostProcessor$LifecycleMetadata.invokeInitMethods(InitDestroyAnnotationBeanPostProcessor.java:311) ~[spring-beans-4.3.9.RELEASE.jar!/:4.3.9.RELEASE]
at org.springframework.beans.factory.annotation.InitDestroyAnnotationBeanPostProcessor.postProcessBeforeInitialization(InitDestroyAnnotationBeanPostProcessor.java:134) ~[spring-beans-4.3.9.RELEASE.jar!/:4.3.9.RELEASE]
... 23 common frames omitted

I am running ubuntu 16.04 and attempting to get jminer up and going, I have already configed my props file and pathed the plot files but when attempting to run jminer from command line with ./run.sh I get the following TB:

Exception in thread "readerPool-1" org.jocl.CLException: CL_OUT_OF_RESOURCES
at org.jocl.CL.checkResult(CL.java:808)
at org.jocl.CL.clEnqueueNDRangeKernel(CL.java:20823)
at burstcoin.jminer.core.checker.util.OCLChecker.findLowest(OCLChecker.java:223)
at burstcoin.jminer.core.checker.task.OCLCheckerTask.run(OCLCheckerTask.java:71)
at org.springframework.core.task.SyncTaskExecutor.execute(SyncTaskExecutor.java:50)
at burstcoin.jminer.core.checker.Checker.handleMessage(Checker.java:72)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at org.springframework.context.event.ApplicationListenerMethodAdapter.doInvoke(ApplicationListenerMethodAdapter.java:253)
at org.springframework.context.event.ApplicationListenerMethodAdapter.processEvent(ApplicationListenerMethodAdapter.java:174)
at org.springframework.context.event.ApplicationListenerMethodAdapter.onApplicationEvent(ApplicationListenerMethodAdapter.java:137)
at org.springframework.context.event.SimpleApplicationEventMulticaster.invokeListener(SimpleApplicationEventMulticaster.java:167)
at org.springframework.context.event.SimpleApplicationEventMulticaster.multicastEvent(SimpleApplicationEventMulticaster.java:139)
at org.springframework.context.support.AbstractApplicationContext.publishEvent(AbstractApplicationContext.java:383)
at org.springframework.context.support.AbstractApplicationContext.publishEvent(AbstractApplicationContext.java:350)
at burstcoin.jminer.core.reader.task.ReaderLoadDriveTask.load(ReaderLoadDriveTask.java:140)
at burstcoin.jminer.core.reader.task.ReaderLoadDriveTask.run(ReaderLoadDriveTask.java:96)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)

Any assistance with this issue would be greatly appreciated.

as connectionTimeout seams to be a problem sometimes ...

• log a speaking exception to inform user
• try to recommit nonces, if first commit fails (with maybe doubled connection timeout?!)

Hello,

I'm getting this error. I searched at the forums and can't find a solution. I tried to increase the timeout to 120 seconds. Also to disable the walletServer=

It's a bug or a misconfiguration? thank you.

When I run CPU mining directly from wallet, it show all my drives and full capacity is scanned.
When I run Jminer with AMD rx 580 GPU, it just showing 2 drive and not rest of the drives. When I remove these 2 drives from list it end up showing zero drives. I do not see any plotting issue as CPU miner is still able to recognize all drives? Any known issue related to this?

I am often getting nonce 'NOT confirmed' in the miner and missing a feature that would retry submitting, just like the winnerRetriesOnAsync for getting the winner.

Is this already such feature I've missed?

Every time I change anything in the properties file and save it resets the file to what the original file was. Do I have to change the original file(PROPERTIES_ORIGINAL...) to get it to save my changes to the non-original file?

• number of mined blocks
• number of chunks/drive seeks

should make it more easy to release a new version

some info about current used pool should be displayed on startup,
so user can be sure, that everything is setup correctly.

Hi i have a pc with a intel gpu opencl work (try with pascal mining on sgminer is slow but he work)
is possible to use intel gpu?

open cl error.log

Hi,

sry to bug you 🐫. I got a problem using jminer (0.4.11-SNAPSHOT) in combination with the latest version of Qbundle. Right now I use BlagoMiner which works. Yet I would like to try jminer due to reading-speed and system-stability.

Problem when I start jminer is, it works for one round. When next round starts I get one line "Unable to get mining info from wallet" then a second time but this time with a java Exception. This exception is only visible when debugging mode = true.

This will then be repeated in every few minutes.

I post the whole log file. Maybe you can help me, thanks.
Sebastian

2017-12-22 20:00:51.824  INFO 1124 --- [roundPool-1] burstcoin.jminer.JMinerCommandLine       : FINISH block '439209', best deadline 'N/A', round time '113s 472ms'
2017-12-22 20:03:38.436  WARN 1124 --- [SimpleAsyncTaskExecutor-142] b.j.c.n.t.NetworkRequestMiningInfoTask   : Unable to get mining info from wallet.
2017-12-22 20:03:38.448 DEBUG 1124 --- [SimpleAsyncTaskExecutor-142] b.j.c.n.t.NetworkRequestMiningInfoTask   : Unable to get mining info from wallet: null

java.lang.IllegalArgumentException: null
	at java.base/java.util.concurrent.ThreadPoolExecutor.setCorePoolSize(Unknown Source) ~[na:na]
	at org.springframework.scheduling.concurrent.ThreadPoolTaskExecutor.setCorePoolSize(ThreadPoolTaskExecutor.java:100) ~[spring-context-4.3.9.RELEASE.jar!/:4.3.9.RELEASE]
	at burstcoin.jminer.core.reader.Reader.read(Reader.java:177) ~[classes!/:0.4.11-SNAPSHOT]
	at burstcoin.jminer.core.round.Round.handleMessage(Round.java:181) ~[classes!/:0.4.11-SNAPSHOT]
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[na:na]
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) ~[na:na]
	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) ~[na:na]
	at java.base/java.lang.reflect.Method.invoke(Unknown Source) ~[na:na]
	at org.springframework.context.event.ApplicationListenerMethodAdapter.doInvoke(ApplicationListenerMethodAdapter.java:253) ~[spring-context-4.3.9.RELEASE.jar!/:4.3.9.RELEASE]
	at org.springframework.context.event.ApplicationListenerMethodAdapter.processEvent(ApplicationListenerMethodAdapter.java:174) ~[spring-context-4.3.9.RELEASE.jar!/:4.3.9.RELEASE]
	at org.springframework.context.event.ApplicationListenerMethodAdapter.onApplicationEvent(ApplicationListenerMethodAdapter.java:137) ~[spring-context-4.3.9.RELEASE.jar!/:4.3.9.RELEASE]
	at org.springframework.context.event.SimpleApplicationEventMulticaster.invokeListener(SimpleApplicationEventMulticaster.java:167) ~[spring-context-4.3.9.RELEASE.jar!/:4.3.9.RELEASE]
	at org.springframework.context.event.SimpleApplicationEventMulticaster.multicastEvent(SimpleApplicationEventMulticaster.java:139) ~[spring-context-4.3.9.RELEASE.jar!/:4.3.9.RELEASE]
	at org.springframework.context.support.AbstractApplicationContext.publishEvent(AbstractApplicationContext.java:393) ~[spring-context-4.3.9.RELEASE.jar!/:4.3.9.RELEASE]
	at org.springframework.context.support.AbstractApplicationContext.publishEvent(AbstractApplicationContext.java:347) ~[spring-context-4.3.9.RELEASE.jar!/:4.3.9.RELEASE]
	at burstcoin.jminer.core.network.task.NetworkRequestMiningInfoTask.run(NetworkRequestMiningInfoTask.java:110) ~[classes!/:0.4.11-SNAPSHOT]
	at java.base/java.lang.Thread.run(Unknown Source) [na:na]

a support to configure/use multiple openCL devices should be added

seams that wallet stops sync. if not ui is open in browser/no request for longer time.
add timed request, to ensure wallet (and miner) does not stuck on solo mining.

currently only gpu openCL devices are 'allowed' ... enable all available.

additional info like:

• your pool found a block
• you found a block
  maybe:
• solo blocks in last 24h
• pool blocks in last 24h
  something like that.

Is it possible somehow to split the plotPaths parameter into multiple drives? I have more than 20 drives and it's a bit cumbersome to edit.

Hello,
any help with this bugs? im using Java_Runtime_Environment_(64bit)_v8_Update_131 and jminer 0.4.11...appreciate it ... much thx

Way too much of the verbage displayed by this miner is totally worthless to folks using it - pretty much everything between the time/date and the : (colon) is just wasted characters that make this miner a royal PAIN TO USE on machines that do not have a incredibly wide display.
I also believe the time and date stamping is way excessive and also just makes the display excessively wide.

I get an error 6676 for all my drives and 0 GB. I have them in the config file as C:\Burst\Burst1 but when I start the miner they show up as C:BurstBurst1 with out slashes. I have tried forward slashes, back slashes as well as trying to use an extra escape slash but it did not work. Any thoughts?

Some pools support request-header fields 'X-Miner' and 'X-Capacity' (in GB), this info should be added.

create internal lookup with real number of nonces for plot-files, were size and specified size from filename does not match, to prevent checker from checking empty buffer.

additional details about winner account are wanted by some users. e.g. name, description ... however it should be possible to disable that, if not wanted.