DICOM @ OFFIS

My question is solved by adding these code:
It seems to relate some default settings and the order of transfer syntax ?
don't know why it works.

thank you for your reply:

My SCP have to store the dicom with Explicit VR Little Endian,
and other tool can do this (e.g. CSImport or storescu.exe)
when I use these tools as a client to send the original dicom.

What can I do with my SCP/SCU ?

I think the problem is that my application sends/receives inappropriate syntax. similar to this one: http://www.mirthcorp.com/community/forums/showthread.php?t=3709 Should we use dcmconv ? Specific Infomation: The original dicom[send by scu] https://dl.dropboxusercontent.com/u/11252568/origin.dcm Th...

hi: there are some of the tags: 0033,1014 0033,1015 0033,1020 0033,1021 0033.1024 0033,1025 0033,1028 0033,1029 0033,1031 0033,1031 <-- this one is automatic generated, should not be here 7FE0,0010 Pixel Data <-- is minor changes normal ? transfer syntax: ts.push_back(UID_LittleEndianExplicitTransfe...

to transmit dicom via the command line tool remains the original values of all private tags,
but the value changes when I using dcmStorageSCU.

The Server side is dcmStorageSCP.
Could anyone give me some suggestions?

I found the reason that I put some SCP server side related codes in the main thread.
And the SCU client also uses the main thread,so there is a dead lock.
After I put all the server codes to another thread, the problem is solved.

I have a problem that "sendSOPInstances" takes a minute to process when I using DcmStorageSCU. but it is ok when I use the command line tool to send dicom to localhost. storescu -aet ANY-SCU -aec ORTHANC 127.0.0.1 104 C:\dicom\0001.dcm The following is the console message of using storescu...