I'm doing some speech recognition using HTK (HMM ToolKit) and I'm getting this odd error:
ERROR [+7390] StepAlpha: Alpha prune failed sq(16) > qHi(15)
I have tried to play around with pruning but only those 15/16 would change to other numbers, I keel receiving the same error. I've even tried to disable pruning and it keeps giving me this error.
I just don't know where to look for anything, if I knew I could fix it.
this is my HERest command:
HERest -C config -I Label.mlf -t 250 100 1000 -S trainlist.scp -H hmms\0\vFloors -H hmms\0\hmm0 -M hmms\1 wordlist
I've looked into the HTK book but there is nothing about the error number 7390.
I work with the HTK toolkit off and on, but not with HEREST. I also have never seen the error that you have encountered. A quick search on the web reveals some links that may be helpful.
Link 1
Scroll to the bottom of the link above, and you see an error code like ??9?. This means that a sanity check has failed. It further says that the error has nothing to do with your code, but that the HTK itself may be faulty. I think, given that Error 7390 has not occurred any where else, and that it also fits your error code, you might want to consider re-installing HTK.
Link 2
The link above shows a lot of common errors and its causes seen when working with the HTK toolkit. The original poster has painstakingly put up errors and common conditions that cause them. Saved me a lot of effort. In my eyes, she deserves the Nobel (or something like that).
Link 3
This link gives more detailed, module by module error codes. Also worth a look.
Do let me know here how you were able to solve your problem.
HTH,
Sriram.
In my case it was related to big (15 MB) file in input data. It worked after deleting it. Run HERest with -T 1 option to see which file causes problem, then remove or split it.
You must adjust -t parameter. This error occur when pruning is failed, so with modify prune parameter. I have this problem and with -t 10 it's solved!
Related
I have 1 running server for handle C-Move, 2 running server for handle C-Store and remote pacs server(GEPACS)
When i tried to C-Move command from remote pacs to C-Store handler, 1 server(py-netdicom) is build and save the file properly and 1 server(go-netdicom) is not.
So there was couple of problems in go-netdicom.
I fixed the code can handle hexadecimals. It originally not supported on go-netdicom.
This was fix almost every problems in my case but still cannot store pixel data properly.
For example, I got 9117252 bytes from original signal from remote pacs and I saved the data itself, but actually it needs to be 18000000 bytes(got an error). even CT images are short for 3 times(got approximately 180000, but need 524288)
I think the problem caused by might be the encapsulation of pixel-data but not sure.
Is there any tip or some help?
Thank you.
EDIT 4: I've got a clue.link here
Somehow C-STORE command have a kind of transfer syntax.
This offer to scp type(compressed or not) of data scu get.
But still I don't have a idea which part of go-netdicom has to be changed.
I'll delete "python" tag because this is not related with python anymore.
I found the solution.
Somehow, GEPACS send the certain transfer syntax for JPEG compression.
if go-netdicom doesn't have the TransferSyntaxUID then pick the GEPACS's first transfer syntax and that was for JPEG compression.
i just put bigendian and explicitvr (GEPACS default) when transfersyntax is empty.
which placed in contextmanager.go line 101 on AssociateRequest, line 127
Hope this result help someone.
Thank you
The problem here is that go-netdicom uses the first PresentationContext sent in the A_ASSOCIATE_RQ (As you can see in the last image). So it accepts "2.16.840.1.113709.1.2.2" which is a privative Transfer Syntax and it is not in the DICOM standart, so no one can manage the C-STORE at the end.
If you are reading this.. maybe you do not use go-netdicom but the problem could be the same if the error involves the transfer Syntax "2.16.840.1.113709.1.2.2", in the Centricity PACs documentation says: "It is expected that other vendors' applications will ignore all Presentation Context proposed with the GE Private Compress Express Transfer Syntax"
And that is what we are suppose to do. I see a list of PRs in go-netdicom so I suppose it is not mantained, so I will post the change for go-netdicom here. I made this changes in contextmanager.go and works like a charm:
I have udev rule with the following content:
DRIVERS=="adt7310", RUN+="/bin/ln -s /sys//devices/platform/soc/fff00000.spi/spi_master/spi0/spi0.0/temp1_input /dev/temperature_adt"
The problem is that this rule is applied twice and in the log appears annoying line:
localhost systemd-udevd[1104]: Process '/bin/ln -s /sys//devices/platform/soc/fff00000.spi/spi_master/spi0/spi0.0/temp1_input /dev/temperature_adt' failed with exit code 1.
I have seen a lot of similar issues over the internet and many of them still unresolved. But most of them were about PC's and quite complicated rules.
Here it is an embedded system, the link is created, nothing wrong happens but I simply don't know what to tell to QA people...
Thanks
Please be very careful when writing rules and especially when you are taking someone else rules. Always run
udevadm info -a /sys/...device
and read very carefully the information.
In my case the solution is
DRIVER=="adt7310" instead of DRIVERS=="adt7310"
My apologies
OK so I recently started getting into programming simple programs and I have taught myself everything using guides on the internet thus far and I have been doing really well and things have been working great, until now. So i feel that I have done a lot, A LOT of searching on this question and I cant seem to find an answer or even anyone else out there that is having the same problem as me. Im going to try to make this as simple as possible so here it goes.
I have made a program in visual studio that is simply supposed to allow me to make entries in fields such as first name, last name, and so on. It works like a charm and saves data like normal, I can close out and re open it and the data is there. BUT
While messing with the program and trying to test it I found that if I DELETED a row of data that i had previously inserted then added ANY new data then clicked the SAVE button it would crash every single time.
First it would say there is no proper delete command. So i gave it one, and it stopped giving me that error message. Then it said it was the update command. So i gave it one then that stopped showing up. But now it gives me the error message. "There was an error parsing the query. [ Token line number = 1,Token line offset = 13,Token in error = , ]. And it gives me this error every time i try to save after following the above steps. And I honestly dont know what to make of it.
I know im going to need to post a sample of my code that I have but I dont know what part of it to post so I figured I would wait and see so I dont post 1,500+ lines on here.
This is the only thing preventing my program from working correctly and if I wouldnt ask if I wasnt completely stumped. And im roughly 300% stumped. So any help would be greatly appreciated.
I'm trying to debug why a change I made isn't working as it should. It's quite strange because there's two different builds of this driver running simultaneously (mpt2sas and mpt3sas) and the change is such that it's identical for both. The change works in mpt2sas but not in mpt3sas. I've got to figure out why. My first thought: print out what is actually being inspected by the driver.
To that end, I've read stuff from here and have referenced a few links from Stack Overflow about similar problems (e.g. this answer and this question). My current printk levels:
[root#dmandylnx64 ~]# cat /proc/sys/kernel/printk
8 4 1 7
Yet, I see no output when I do something like this:
dmesg | less # and search around for my strings
I found another link stating that the kernel buffers are made available through /proc/kmsg. So, I did
cat /proc/kmsg
... still not dice. I run my program and see no printks. One of the links I provided above stated something like, "... changing printk to pr_info did the trick ...". Well, I tried that too.
printk(KERN_DEBUG "MPT3SAS: 0x%08x\n", someIntegerData);
// became
pr_dbg("MPT3SAS: 0x%08x\n", someIntegerData);
Nope, that didn't work either. I upped the priority by changing them from DEBUG level to INFO level. Nope, that didn't work.
The question is really simple: what am I missing?
edit I forgot to mention, not even sure it is relevant, but this is CentOS 6.5.
Thanks,
Andy
I'm trying to download a small zip file (1159 bytes) and pipe it through funzip. This works great with larger files fro that server. However three small files give me an error:
Broken pipe, closing control connection.
I use the following code:
wget -O - --ftp-user=username --ftp-password=secret ftp://server/small-file.zip | funzip
Also downloading the file directly works good, only the piping to funzip doesn't work. I suspect the file is too small.
Anyone knows how to fix this?
Edit: Size doesn't seem to matter (don't let the girls tell you otherwise :)), even files of 400 bytes are not giving errors
Ok, if nobody can answer it, I'll answer it myself
I found there are two solutions, one is limiting the download rate for wget
--limit-rate=1000
This works for the files of around 1kb but now sometimes larger files seem to suffer from the same error. It also slows down the whole process.
Now I just pipe the download through a script that sleeps 1 second at the end. This seems to solve it.