VOD高手请过来，有谁这么写过神龙卡回调函数？？

Question

一般神龙卡的回调函数中包含：
    case FMPM_BUF_SEEK: SetFilePointer( Buf->hFile, (LONG)dwValue, 0, FILE_BEGIN );
    case FMPM_BUF_POS: ReadFile( Buf->hFile, Buf->Buffer[Buf->wIndex], MAX_BUF_SIZE,&Buf->dwSize, NULL );
  
    现在我的想法是先把歌曲文件从服务器中分段读取到本地计算机的虚拟内存中，然后使用copymemory的方法把这些数据拷贝到神龙卡的内存中，实现播放，也就是把ReadFile换掉。
    测试中，具体播放是没有问题的，只是在一首歌强制中断播放后（停止并关闭流），发现在下一首歌中的开始部分会丢失1~2M的数据，而那个地方有的时候是非常重要的，经常不出现歌名，甚至一开始歌手就已经唱过了半句……敢问各位高手有什么好的方法可以解决呢？我的case FMPM_BUF_SEEK:中不知道该怎么去定位指针，就没写语句！若问题解决马上给分，我可以再出100分。

Answer 1

谢谢delphi2java(delphi2java) 
我在专区里也发了该帖，若您需要，
也可去看看

Answer 2

没有这样写过，但看你的说明，加段代码重新初始化神龙卡再试试hehe^^为什么要这样写程序有什么好处吗？还是有什么特殊要求？

Answer 3

to CDSoftwareWj:
      神龙卡我以前重新初始化过（现在我用的就是重新初始化的，只是没有关闭后重新打开），效果一样！
      这样写简单的说，一个最基本的就是网络资源占用明显会减少！

Answer 4

to CDSoftwareWj:
    你可以想想，呵呵，假设我一个服务器可以带50个点，那么我只要10个硬盘，我就可以装载下
1万多首歌曲！
    你那个在50个点的时候需要多少个硬盘？假设一个硬盘500，那么不算后台服务器硬盘，成本要
多少？

Answer 5

1. 映射网络驱动  ---- 小一点的地方，点少一点的地方可以用，很稳定，最初的一些公司也都是这样做的，但缺点很明显---------------
  你可以这样做，和你说的效果一样 hehe^^

Answer 6

缺点呀，就是点播的点一多比如50个以上.....（其时30个以上时）就不稳定了，对网络流量需求也大，容易死机，我以前做VOD时，好多这种点播方式的系统都叫我们的VOD系统换掉了，就应为不稳定，影响生意 hehe^^

Answer 7

谢谢
不过我们这里测试了，现在我们用一个IDE硬盘，的确带到了50多个点以上：）